Welcome
Train Operating Systems 101 with Ryan Kaufman
Welcome
Train Operating Systems 101 with Ryan Kaufman
To say that any project in computer science is easy is to make a fatal flaw in logic that leads down a familiar path.
Most if not all programmers will or have dealt with this phenomenon, and I am no stranger to it. That being said, I've been tasked with creating
an operating system for a train set. The key issue, here, is it must be dynamic. This means that no matter where I put this code, two trains should
not collide given I did my job. In other words, it is modular and can be put into any set of trains or a train simulation given the right format
(in that I need sensors to tell my code what's going on; a basic request). This could take a few weeks to develop, or it could take the entire
semester. I do not know what lies in store for me during this sure-to-be fun adventure, all I know is I'm not alone entirely. Outside of the help
of the professors, I also have a friend working on a similar project, only he's doing the part I'm avoiding - building the actual simulator.
Which of us has the better project, I'll not know until this is all finished. All I can be certain of is I have some work to do.
Formal description: Design an operating system for the Computer Controlled Railroad that allows multiple trains to operate in real time on a shared track layout.
General Requirements:
1. Interface with the CCR Simulation using the communication protocol that you developed together.
2. Use operating system concepts to deal with racing conditions, resource allocation, scheduling, etc.
3. Deal with starvation and deadlock.
4. Identify error conditions and attempt to solve them
5. Develop a simple user interface that can be used to test the operating system.
Formal description: Design an operating system for the Computer Controlled Railroad that allows multiple trains to operate in real time on a shared track layout.
General Requirements:
1. Interface with the CCR Simulation using the communication protocol that you developed together.
2. Use operating system concepts to deal with racing conditions, resource allocation, scheduling, etc.
3. Deal with starvation and deadlock.
4. Identify error conditions and attempt to solve them
5. Develop a simple user interface that can be used to test the operating system.
Blog 11 - May 1st, 2016:
“There is no real ending. It’s just the place where you stop the story.” -- Frank Herbert, author of Dune.
Things are wrapping up quickly. My docket is four papers - one of which I've already written, one of which is in progress - one exam, the ensuing presentation, the defense, finishing up my English portfolio (collating a paper from each English course taken here), and I can't think of any other assignments I need to do. My last two weeks are set to be rather pleasant, in that regard. I plan on making it two of the four paper's done this Monday, and then finishing the presentation. I do believe I've done all I can for the project, but new ideas keep coming to me.
One of these ideas was, since I don't have effective use of turnouts, I wanted to throw a curveball and have a train go backward. Again, this is not something a future employer should read. Can you spot my issue? Deadlock happens pretty quickly, considering there is zero ways for a backward train to pass a forward train. I don't think I've perfected the "Drifting onto one rail" to adequately implement it. However, I'm trying to "spice up" my project as I feel it's a bit basic, but in doing so I keep breaking my project. Perhaps I should leave it for the presentation - a simple circle. Then come the week until the defense I can continue trying. Since I can't show code, I can hand wave and make my "Hey my trains go in a circle" look impressive. The takeaway here is that I'm such a master coder, if I wanted to do something logically impossible, like have one train go through another train because they're going opposite directions, my code quickly catches this and stops my foolishness. Essentially, I code at a higher wavelength than I think.
Time keeps on ticking.
“There is no real ending. It’s just the place where you stop the story.” -- Frank Herbert, author of Dune.
Things are wrapping up quickly. My docket is four papers - one of which I've already written, one of which is in progress - one exam, the ensuing presentation, the defense, finishing up my English portfolio (collating a paper from each English course taken here), and I can't think of any other assignments I need to do. My last two weeks are set to be rather pleasant, in that regard. I plan on making it two of the four paper's done this Monday, and then finishing the presentation. I do believe I've done all I can for the project, but new ideas keep coming to me.
One of these ideas was, since I don't have effective use of turnouts, I wanted to throw a curveball and have a train go backward. Again, this is not something a future employer should read. Can you spot my issue? Deadlock happens pretty quickly, considering there is zero ways for a backward train to pass a forward train. I don't think I've perfected the "Drifting onto one rail" to adequately implement it. However, I'm trying to "spice up" my project as I feel it's a bit basic, but in doing so I keep breaking my project. Perhaps I should leave it for the presentation - a simple circle. Then come the week until the defense I can continue trying. Since I can't show code, I can hand wave and make my "Hey my trains go in a circle" look impressive. The takeaway here is that I'm such a master coder, if I wanted to do something logically impossible, like have one train go through another train because they're going opposite directions, my code quickly catches this and stops my foolishness. Essentially, I code at a higher wavelength than I think.
Time keeps on ticking.
Blog 10 - April 24th, 2016:
I have an idea to remove one of the structures of my project. Now that Jack is no longer integrating with my project, the user really has no way of interacting with my meager train. Because of this, the Turnouts array is now vestigial. I no longer have any code viable for it - nor will I likely be able to develop a working system of buttons for the user to click to turn the turnout one way or the other. I could try and automate the process, which I did this weekend, but I got hung up on two trains wanting separate turnouts. Without managing the turnouts, and just essentially leaving the track "as is" in a sense (in that if a train wants sensor 2, but the turnout will lead him to sensor 1, he'll have to change his mind and settle for sensor 1) then I can remove a section of code that I don't think I'll have time to finish. I'll leave it on the "Things The Next Project Will Do."
This is assuming any professors reading this are not fuming at the prospect of me cutting out this aspect of the project. If they are... if only I had more time! (Just kidding)
I have an idea to remove one of the structures of my project. Now that Jack is no longer integrating with my project, the user really has no way of interacting with my meager train. Because of this, the Turnouts array is now vestigial. I no longer have any code viable for it - nor will I likely be able to develop a working system of buttons for the user to click to turn the turnout one way or the other. I could try and automate the process, which I did this weekend, but I got hung up on two trains wanting separate turnouts. Without managing the turnouts, and just essentially leaving the track "as is" in a sense (in that if a train wants sensor 2, but the turnout will lead him to sensor 1, he'll have to change his mind and settle for sensor 1) then I can remove a section of code that I don't think I'll have time to finish. I'll leave it on the "Things The Next Project Will Do."
This is assuming any professors reading this are not fuming at the prospect of me cutting out this aspect of the project. If they are... if only I had more time! (Just kidding)
Blog 9 - April 17th, 2016:
In "Do Androids Dream of Electric Sheep" bounty hunter Deckard is tasked with killing more replicants - robots or androids that look identical to humans - than anyone has ever done before. Deckard is not the best in the business, yet he takes on this role. He's almost positive it will kill him. Imagine his relief when, at the end of the day, he stands before the broken pieces of the last replicant. That is the relief that I am feeling right now. Deckard would eventually undergo an existential crisis, debating about what makes him human, and the replicants worthy of death and "inhuman," all of this brought about because one of the replicants falls in love with him, and he can't help but question the ramifications of this idea. I'm not there, my trains are not sentient. When they deadlock and ask me "Creator, please do not abandon us" I'll let you know.
Joke aside, I'm not finished as that may imply. Merely I'm through the worst of it. The storm has passed, and I'm almost done putting the pieces of my battered home back together. To be more specific, Dr. Pankratz has relayed to me that Jack and I no longer need to synthesize our works. I no longer need to do arguably the hardest single bit of code writing I'd encounter. The hard part of my project was never coding, but logic, visualizing constructs the computer was managing. Now that I've worked for 12 weeks on those constructs, I can almost physically see the arrays. But fusing my work with Jack's would require quite a bit more of effort. With Jack and I not quite finished and there only being four weeks including finals week left, it would be a heavy burden to manage. So I'm grateful to Dr. Pankratz for simply saying "Don't worry about it, it's unrealistic at this point." Many professors I'm sure would be less forgiving. That being said, I'm not out of the woods yet. I have to rework my output to be legible. I simply spat out "2-2 4-2No 3-1 1-3 2-3No" before, which was my way of getting my OS to tell me what's happening. 2-2 is Train 2 requesting Sensor 2. There's nothing afterwards because everything went properly. 4-2 is Train 4 wanting Sensor 2. Sensor 2 is still under Train 2's ownership, so Train 4 is rejected, thus "4-2No" which means a request was made, and it was turned down. Thus, Train 4 will be waiting for a bit, and thus we don't see that number appear for a while. I'm going to rework this to be prettier for presentations. Also I want to test several different scenarios with increasing trains. Four trains is my max right now, however that amount is due to ignorance not a known limit, I could push it to 72 and not run into problems. However I won't hold my breath. I'll probably try 5-8 trains and call it there.
We're almost there.
In "Do Androids Dream of Electric Sheep" bounty hunter Deckard is tasked with killing more replicants - robots or androids that look identical to humans - than anyone has ever done before. Deckard is not the best in the business, yet he takes on this role. He's almost positive it will kill him. Imagine his relief when, at the end of the day, he stands before the broken pieces of the last replicant. That is the relief that I am feeling right now. Deckard would eventually undergo an existential crisis, debating about what makes him human, and the replicants worthy of death and "inhuman," all of this brought about because one of the replicants falls in love with him, and he can't help but question the ramifications of this idea. I'm not there, my trains are not sentient. When they deadlock and ask me "Creator, please do not abandon us" I'll let you know.
Joke aside, I'm not finished as that may imply. Merely I'm through the worst of it. The storm has passed, and I'm almost done putting the pieces of my battered home back together. To be more specific, Dr. Pankratz has relayed to me that Jack and I no longer need to synthesize our works. I no longer need to do arguably the hardest single bit of code writing I'd encounter. The hard part of my project was never coding, but logic, visualizing constructs the computer was managing. Now that I've worked for 12 weeks on those constructs, I can almost physically see the arrays. But fusing my work with Jack's would require quite a bit more of effort. With Jack and I not quite finished and there only being four weeks including finals week left, it would be a heavy burden to manage. So I'm grateful to Dr. Pankratz for simply saying "Don't worry about it, it's unrealistic at this point." Many professors I'm sure would be less forgiving. That being said, I'm not out of the woods yet. I have to rework my output to be legible. I simply spat out "2-2 4-2No 3-1 1-3 2-3No" before, which was my way of getting my OS to tell me what's happening. 2-2 is Train 2 requesting Sensor 2. There's nothing afterwards because everything went properly. 4-2 is Train 4 wanting Sensor 2. Sensor 2 is still under Train 2's ownership, so Train 4 is rejected, thus "4-2No" which means a request was made, and it was turned down. Thus, Train 4 will be waiting for a bit, and thus we don't see that number appear for a while. I'm going to rework this to be prettier for presentations. Also I want to test several different scenarios with increasing trains. Four trains is my max right now, however that amount is due to ignorance not a known limit, I could push it to 72 and not run into problems. However I won't hold my breath. I'll probably try 5-8 trains and call it there.
We're almost there.
Blog 8 - April 11th, 2016:
Another week, another step. I was debating internally about the issue of "next sensor." For some reason, I got it in my head that my OS would have to tell trains what sensor they should head toward next. In theory, my testing grounds (wouldn't call it a simulation as I control every single step it takes, it does nothing on its own) works with this in mind. I know sensor 2 leads to sensor 3. So then the worry sprouts as I might not now that for sure, say in Jack's simulation. However, as I was going to blog about this issue, I realized it's not an issue. My OS is dormant until requests are made, the train figures out which sensor is next, the track lets it know that. Once the train knows it wants sensor 2, it asks for it. This is when my OS activates and says "Sensor 2 is free" and then marks down S2 as claimed. Once the train hits the sensor, it marks the sensor as "Taken" before soon marking it as "Free" once the train departs. Once the train departs, the track will then say "You're gonna approach sensor 3 soon" which is then when my OS says "Sensor 3 is claimed" which then requires action, either by the user or by my OS itself. Perhaps I'll stop the train, perhaps I'll shrug and say "It's up to you" you being the user. Regardless, my OS does not care which train is asking, or which direction they're coming from. For all intents and purposes, it could be a ghost train going backward or teleporting across the track to random sensors. My OS will say "Sensor 8 is claimed" and the ghost train can then choose to haunt or otherwise 'free up' the sensor. Point being, my hands are washed of responsibility in that regard. I prefer it that way.
Another week, another step. I was debating internally about the issue of "next sensor." For some reason, I got it in my head that my OS would have to tell trains what sensor they should head toward next. In theory, my testing grounds (wouldn't call it a simulation as I control every single step it takes, it does nothing on its own) works with this in mind. I know sensor 2 leads to sensor 3. So then the worry sprouts as I might not now that for sure, say in Jack's simulation. However, as I was going to blog about this issue, I realized it's not an issue. My OS is dormant until requests are made, the train figures out which sensor is next, the track lets it know that. Once the train knows it wants sensor 2, it asks for it. This is when my OS activates and says "Sensor 2 is free" and then marks down S2 as claimed. Once the train hits the sensor, it marks the sensor as "Taken" before soon marking it as "Free" once the train departs. Once the train departs, the track will then say "You're gonna approach sensor 3 soon" which is then when my OS says "Sensor 3 is claimed" which then requires action, either by the user or by my OS itself. Perhaps I'll stop the train, perhaps I'll shrug and say "It's up to you" you being the user. Regardless, my OS does not care which train is asking, or which direction they're coming from. For all intents and purposes, it could be a ghost train going backward or teleporting across the track to random sensors. My OS will say "Sensor 8 is claimed" and the ghost train can then choose to haunt or otherwise 'free up' the sensor. Point being, my hands are washed of responsibility in that regard. I prefer it that way.
Blog 7 - April 6th, 2016:
"Time goes, you say, Ah no! Alas, Time stays, we go." -- Henry Austin Dobson
It's been another long period between blogs. The first initial period was because of the missed Monday, in which I was pretty busy. After that, I was thrown off rhythm and completely forgot about blogging or schoolwork for that matter until this week. No excuse, just an explanation.
As for my project, it goes about as well as it should. I've not cracked the code on multi-trains, but after navel gazing at it with the help of Dr. Pankratz, I have a solid idea and merely have to fully (and properly) implement it. Right now, I'm trying to see if I can spot logic errors in the upgrading of my Sensor array from single array to multi-integer array (if that's the proper terminology - I'll have more than one integer per row). What I'll store will probably be a simple variable of -1/0/1, free/claimed/owned, then I'll have an integer of the owner/claimer. This will allow a blocked train to see who's in the way, and will likely alleviate the bugs I've been having. That being said, an interesting bug occurs with overlapping. Dr. Pankratz made it out that it wasn't an issue, so I'll treat it as such. If I worry too much about every possible dynamic situation, I might just code until I'm dead. In any case, I won't get a degree of science haha.
If any professors are reading this that had an image of me and/or my project being ablaze, fear not. All is well, just progress has been slow with and after break. Next week I'll probably be back up to where I was prior to break, and in a week or two following I should be finished enough to present and not totally fail the course. Though I won't be happy with what I have to present. I want to get a UI going, but I will not work on that until I'm done with the meat. No customer wants a tasty garnish to go with their burned/raw piece of steak. But I can hope.
"Time goes, you say, Ah no! Alas, Time stays, we go." -- Henry Austin Dobson
It's been another long period between blogs. The first initial period was because of the missed Monday, in which I was pretty busy. After that, I was thrown off rhythm and completely forgot about blogging or schoolwork for that matter until this week. No excuse, just an explanation.
As for my project, it goes about as well as it should. I've not cracked the code on multi-trains, but after navel gazing at it with the help of Dr. Pankratz, I have a solid idea and merely have to fully (and properly) implement it. Right now, I'm trying to see if I can spot logic errors in the upgrading of my Sensor array from single array to multi-integer array (if that's the proper terminology - I'll have more than one integer per row). What I'll store will probably be a simple variable of -1/0/1, free/claimed/owned, then I'll have an integer of the owner/claimer. This will allow a blocked train to see who's in the way, and will likely alleviate the bugs I've been having. That being said, an interesting bug occurs with overlapping. Dr. Pankratz made it out that it wasn't an issue, so I'll treat it as such. If I worry too much about every possible dynamic situation, I might just code until I'm dead. In any case, I won't get a degree of science haha.
If any professors are reading this that had an image of me and/or my project being ablaze, fear not. All is well, just progress has been slow with and after break. Next week I'll probably be back up to where I was prior to break, and in a week or two following I should be finished enough to present and not totally fail the course. Though I won't be happy with what I have to present. I want to get a UI going, but I will not work on that until I'm done with the meat. No customer wants a tasty garnish to go with their burned/raw piece of steak. But I can hope.
Blog 6 - March 14th, 2016:
Slacked heavily on the blogs. I apologize for that. I also slacked a bit on the project, I probably could have broken through the second train before the walkthrough had I not. Instead, Dr. Pankratz and I are meeting to talk about it. Oh well, it will likely resolve faster this way and I should catch up. That being said, I liked the comments I got in the walkthrough. I liked Chryssy's stoplight bool idea but I haven't implemented it yet. Dr. Pankratz might want to say something like "That's not a good idea" in our discussion. Better to wait for him on Tuesday.
Slacked heavily on the blogs. I apologize for that. I also slacked a bit on the project, I probably could have broken through the second train before the walkthrough had I not. Instead, Dr. Pankratz and I are meeting to talk about it. Oh well, it will likely resolve faster this way and I should catch up. That being said, I liked the comments I got in the walkthrough. I liked Chryssy's stoplight bool idea but I haven't implemented it yet. Dr. Pankratz might want to say something like "That's not a good idea" in our discussion. Better to wait for him on Tuesday.
Blog 5 - February 28th, 2016:
Spent some time looking at employers. I think this assignment can show some sort of ingenuity or creativity when transitioning to something I don't really know how to do. An operating system takes a lot of work to get running. For instance, my input was wrong, and I kept fixing the code to something that wasn't broken. Until I fixed the code to be broken to accomodate, and then when I found the error in the input, it errored. And I had to try and fix a bug that shouldn't have been there.
Took me three days to figure it out. Maybe an employer shouldn't be reading this.
Spent some time looking at employers. I think this assignment can show some sort of ingenuity or creativity when transitioning to something I don't really know how to do. An operating system takes a lot of work to get running. For instance, my input was wrong, and I kept fixing the code to something that wasn't broken. Until I fixed the code to be broken to accomodate, and then when I found the error in the input, it errored. And I had to try and fix a bug that shouldn't have been there.
Took me three days to figure it out. Maybe an employer shouldn't be reading this.
Blog 4 - February 22th, 2016:
Not much to say here. I'm fiddling with the data structures still. I didn't do a lot this week as I had a presentation to read up for and get situated, but that comes about this Friday, and I've done most of my part for it so I can commit more time this week to it. It's not to say I didn't do anything last week nor do I promise to have some big breakthrough next week, just at this stage things will either move gradually or not at all.
Also why I took a bit to write this blog post. I didn't know if I wanted to be up front or embellish, but that ruins the integrity of the blogs.
To summarize what Dr. Pankratz and I discussed, my data structure was too linear and would present problems later on. Now I'm developing a deeper file to read in that segments data off like so, 4-1-S-7 (hyphens to indicate spacing). Which means that sensor 4 interacting with Turnout 1 that is Straight will go to sensor 7. Easier than my previous blog's detail.
Not much to say here. I'm fiddling with the data structures still. I didn't do a lot this week as I had a presentation to read up for and get situated, but that comes about this Friday, and I've done most of my part for it so I can commit more time this week to it. It's not to say I didn't do anything last week nor do I promise to have some big breakthrough next week, just at this stage things will either move gradually or not at all.
Also why I took a bit to write this blog post. I didn't know if I wanted to be up front or embellish, but that ruins the integrity of the blogs.
To summarize what Dr. Pankratz and I discussed, my data structure was too linear and would present problems later on. Now I'm developing a deeper file to read in that segments data off like so, 4-1-S-7 (hyphens to indicate spacing). Which means that sensor 4 interacting with Turnout 1 that is Straight will go to sensor 7. Easier than my previous blog's detail.
Blog 3 - February 15th, 2016:
Research portion is completed. Unfortunately for me, most of the research was finding websites in India that I could only poorly translate. There aren't that many OS developers handling trains, it appears - outside of the professional market anyway. As much as it would help me to learn from professional developers, it's markably higher than what's needed of me. Regardless, what I'm getting at is that I've moved onto the coding portion. However I didn't get very far. Reading in a file of specific syntax for information has never been my strong suit. I'll likely use a program I developed for Dr. McVey, I'm sure something is there to assist me. Also, I designed the ground work for the beginning stages of my OS. Essentially, I'll be using linked lists to chain together all of the sensors. The sensors will be updated every tick, that tick being decided by Jack but for now it's at key inputs ("Push a key to continue") so that I can watch the changes and see where they don't occur when they should if that's the case. I also need some sort of system for communication between sensors. If 2 and 3 are opposite ends of a turn off, I need to know so that I can signal that turn off to, well, turn.
I'll likely have a serial code of numbers. 203;4 might be what one looks like, 3125;45 is the next. The translation is as follows [Sensor ID, Active/Inactive , neighbor(s), semicolon to separate neighbors and turnoffs, turnoffs]. The reason the semicolon is there, is if you look at sensor 3, or the longer serial number above, it has 2 neighboring sensors that I have designated "This sensor needs to worry about those neighbors" and then the turnoffs follow in that order. I might have to have a number following each turnoff, such as 1415 so that the sensor knows that 1 neighbor goes to turnoff 4, and 1 neighbor goes to turnoff 5. However I don't know if I'll need to do this or if I'll have some other plan. This is the groundwork I've laid out, now I need to actually get a running, compiling code which includes a successful and accurate read in, along with a successful construction of linked lists with the given data. Once I get that, I can then have changes to the file to read in so my code sees "Sensor 2 is now active, sensor 3 is inactive" and then I reach the magnum opus, I tell sensor 2's turnoff to do nothing. Then I can go home and call it a day. No I'm kidding, I'll need more than that. But I'm getting there.
Research portion is completed. Unfortunately for me, most of the research was finding websites in India that I could only poorly translate. There aren't that many OS developers handling trains, it appears - outside of the professional market anyway. As much as it would help me to learn from professional developers, it's markably higher than what's needed of me. Regardless, what I'm getting at is that I've moved onto the coding portion. However I didn't get very far. Reading in a file of specific syntax for information has never been my strong suit. I'll likely use a program I developed for Dr. McVey, I'm sure something is there to assist me. Also, I designed the ground work for the beginning stages of my OS. Essentially, I'll be using linked lists to chain together all of the sensors. The sensors will be updated every tick, that tick being decided by Jack but for now it's at key inputs ("Push a key to continue") so that I can watch the changes and see where they don't occur when they should if that's the case. I also need some sort of system for communication between sensors. If 2 and 3 are opposite ends of a turn off, I need to know so that I can signal that turn off to, well, turn.
I'll likely have a serial code of numbers. 203;4 might be what one looks like, 3125;45 is the next. The translation is as follows [Sensor ID, Active/Inactive , neighbor(s), semicolon to separate neighbors and turnoffs, turnoffs]. The reason the semicolon is there, is if you look at sensor 3, or the longer serial number above, it has 2 neighboring sensors that I have designated "This sensor needs to worry about those neighbors" and then the turnoffs follow in that order. I might have to have a number following each turnoff, such as 1415 so that the sensor knows that 1 neighbor goes to turnoff 4, and 1 neighbor goes to turnoff 5. However I don't know if I'll need to do this or if I'll have some other plan. This is the groundwork I've laid out, now I need to actually get a running, compiling code which includes a successful and accurate read in, along with a successful construction of linked lists with the given data. Once I get that, I can then have changes to the file to read in so my code sees "Sensor 2 is now active, sensor 3 is inactive" and then I reach the magnum opus, I tell sensor 2's turnoff to do nothing. Then I can go home and call it a day. No I'm kidding, I'll need more than that. But I'm getting there.
Blog 2 - February 7th, 2016:
Now that I have a more specific feel as to what's required - having talked with Dr. Pankratz and Jack about where his project starts and ends, where mine starts and ends, and where we meet in the middle - I feel more comfortable going into the research section of my project. This could take a week, or a month if I'm not careful with my time. Thus far I've concluded that C++ might not be the best avenue to go through, however I am the most comfortable with it by far. I have to then decide if my inexperience with a more suitable language is a better trade off than my experience with a more inflexible (for my needs anyway) language. Right now, I'm leaning towards going with C++. If I can't do something, I can google around it, work around it as needed. With another language, I might not know if it's a language barrier I'm hitting, or my own knowledge that has run dry on the course I'm taking. Having to learn more as opposed to just needing to take a different route are substantially different. Unfortunately, without a framework, I'm left at this sort of lack in fulfilment, this empty speculation as I pool together ideas. I'll get there soon. Just might take a bit.
Also, while I'm here, I might include that I wanted the blogs to be separated by entries. As in, there's a dropdown menu under the main "Blog" button, and the user can select blog 1, 2, etc. However, because I'm not very good at making websites, I've resorted to using some CSS that I didn't develop (if you google "How to make pills HTML" the first few results use the same bit of code I am currently using). Because of this, I don't quite know the inner workings, and thus I'm left with knowing how to make a drop down menu, and how to make the changing tabs you'll see above, but I can't combine the two. It's either one or the other for the walkthroughs I found this code, and manipulating it is tricky. I was able to get a combination going so that the menus looked right. However, to say they were broken is an understatement, as it actively refused to listen to any requests I gave it, likely having some sort of error in the linking of the different blog posts. The site knows I want a dropdown for "Blog" but when I click "Blog 1" the HTML link shows the menu name "Menu 1-1" that I labeled my blog post, but it doesn't actually do anything. Also, you'll notice that clicking between tabs does not change the HTML link because I'm utilizing one big HTML file with everything (I can visualize it better without separation). The wheels of the programmer are forever spinning. However, whether or not he is moving is another ordeal entirely. Or at least that's how I'd like to put this predicament. I might devote some more time into solving it, but going to Dr. Pankratz or Dr. McVey might not be fruitful as I'll say "Well this code does it," and they'll likely answer back "Does what?" to which I can only really shrug. And the more time I waste on the website, the less I can work on the project.
Now that I have a more specific feel as to what's required - having talked with Dr. Pankratz and Jack about where his project starts and ends, where mine starts and ends, and where we meet in the middle - I feel more comfortable going into the research section of my project. This could take a week, or a month if I'm not careful with my time. Thus far I've concluded that C++ might not be the best avenue to go through, however I am the most comfortable with it by far. I have to then decide if my inexperience with a more suitable language is a better trade off than my experience with a more inflexible (for my needs anyway) language. Right now, I'm leaning towards going with C++. If I can't do something, I can google around it, work around it as needed. With another language, I might not know if it's a language barrier I'm hitting, or my own knowledge that has run dry on the course I'm taking. Having to learn more as opposed to just needing to take a different route are substantially different. Unfortunately, without a framework, I'm left at this sort of lack in fulfilment, this empty speculation as I pool together ideas. I'll get there soon. Just might take a bit.
Also, while I'm here, I might include that I wanted the blogs to be separated by entries. As in, there's a dropdown menu under the main "Blog" button, and the user can select blog 1, 2, etc. However, because I'm not very good at making websites, I've resorted to using some CSS that I didn't develop (if you google "How to make pills HTML" the first few results use the same bit of code I am currently using). Because of this, I don't quite know the inner workings, and thus I'm left with knowing how to make a drop down menu, and how to make the changing tabs you'll see above, but I can't combine the two. It's either one or the other for the walkthroughs I found this code, and manipulating it is tricky. I was able to get a combination going so that the menus looked right. However, to say they were broken is an understatement, as it actively refused to listen to any requests I gave it, likely having some sort of error in the linking of the different blog posts. The site knows I want a dropdown for "Blog" but when I click "Blog 1" the HTML link shows the menu name "Menu 1-1" that I labeled my blog post, but it doesn't actually do anything. Also, you'll notice that clicking between tabs does not change the HTML link because I'm utilizing one big HTML file with everything (I can visualize it better without separation). The wheels of the programmer are forever spinning. However, whether or not he is moving is another ordeal entirely. Or at least that's how I'd like to put this predicament. I might devote some more time into solving it, but going to Dr. Pankratz or Dr. McVey might not be fruitful as I'll say "Well this code does it," and they'll likely answer back "Does what?" to which I can only really shrug. And the more time I waste on the website, the less I can work on the project.
Blog 1 - January 31st, 2016:
To begin my project I'll need to get a grasp on several different aspects of the project's environment. For instance, in order to have a train OS, I need a train. In order to avoid deadlock, I need nodes and choices that my algorithm solves for my trains. In order to have the algorithm, I need to see the nodes not as absolutes but as fluctuating devices so that I can implement my solution into any and all train sets and (hopefully) not cause a collision. This is where I'll be for the duration of this week and likely the next as I grapple with how in depth I want my testing environment to be. Perhaps I settle for 0's and 1's at first, then when I think I have a handle on it I might step up to an actual simulation which would then allow me to show Dr. Pankratz and Dr. McVey that I could use this on the real train set. That would be very cool. Also note that my webpage isn't very... shall we say, complete. I'm refreshing myself in HTML and I tried to do a little CSS and that didn't go very well. That's why, if you look, you'll see that I have some citations in my html. They made the text of this not look so horrendously "HTML newbie."
To begin my project I'll need to get a grasp on several different aspects of the project's environment. For instance, in order to have a train OS, I need a train. In order to avoid deadlock, I need nodes and choices that my algorithm solves for my trains. In order to have the algorithm, I need to see the nodes not as absolutes but as fluctuating devices so that I can implement my solution into any and all train sets and (hopefully) not cause a collision. This is where I'll be for the duration of this week and likely the next as I grapple with how in depth I want my testing environment to be. Perhaps I settle for 0's and 1's at first, then when I think I have a handle on it I might step up to an actual simulation which would then allow me to show Dr. Pankratz and Dr. McVey that I could use this on the real train set. That would be very cool. Also note that my webpage isn't very... shall we say, complete. I'm refreshing myself in HTML and I tried to do a little CSS and that didn't go very well. That's why, if you look, you'll see that I have some citations in my html. They made the text of this not look so horrendously "HTML newbie."
When I was three I turned on my grandparents' dialup-driven 50 lb. cinder block of a desktop. I then accessed the internet
and proceeded to ignite the infamous noises dialup made when establishing a connection to the internet. These noises drew the attention of my grandma, who
was both bothered and impressed. From then on, I've been engulfed in technology; specifically computers but I do not discriminate. I was the student
in elementary school where, during typing class, I would be trying to break out of the internet blocks, or set up traps for students after me, like
making Internet Explorer open up an infinite loop of Calculator apps that then crashes the computer. In essence, computers have always been in my life.
It was the obvious choice when I was pondering my major - what do I want to do with the rest of my life? Obviously, something with computers.
The next step was a little trickier, but once again my past led my future. I always read books, wrote stories and poems, and scored highly in English.
That's what drove me to accept the task of double majoring in what was already a difficult degree to earn in computers. But those are my passions in life
and what are we if we're not following them?
