This is a new step in the right direction: companies being accountable to consumers. Thank you, McDonalds.
I am a full-time software engineer with an interest in gadgets and the many technologies making them possible. I also enjoy investing and swing trading. I write for my friends: fellow programmers, IT administrators, and those wise ones who learned to benefit from technology without dedicating their life to it.
Wednesday, June 20, 2012
McDonalds explains photogenic burgers
This is a new step in the right direction: companies being accountable to consumers. Thank you, McDonalds.
Wednesday, June 13, 2012
Most helpful review
Turns out that one of my reviews from 2010 is Amazon's "most helpful review" for this book: The Definitive Guide to CentOS. 25 out of 25, baby!
Arduino, QP, and road intersection requirements
For many months now I've been planning to implement a simple project with the QP framework and its graphical modeler, QM. The QP framework makes it easy to create reactive systems based on the idea of UML statecharts.
Finally I got the motivation to sit down and learn its basics: I am teaching talented high schoolers this summer, and I am going to ask them to verify that a road intersection controller meets its requirements. I implemented this road intersection controller on an Arduino Uno using the QP framework. The sample code supplied with QP was a huge help for this.
Now I see how "tiny" the Arduino Uno is. I am using 10 of its digital ports. It comes with only 13, and I am leaving a strategic three unused because they're spaced so close to each other that some ports have to be skipped to avoid bending pins.
The intersection has four directions (N, S, W, E). Cars approaching from north and south have a basic stoplight without turn arrows. Cars approaching from west and east have a protected left turn arrow. And, all four roads have pedestrian crossing. The intersection "detects" a vehicle waiting in a left turn lane, just like in real life. It also allows a pedestrian to push the crosswalk button. (In reality this means that there are two pushbuttons wired to the Arduino: one for left turn, one for pedestrian crossing.) These two are the only events the Arduino processes, since only two digital pins can have an interrupt attached to them. The remaining ports are wired to LEDs, to display the state of lights.
This was surprisingly easy to implement with the QP framework: I just basically enhanced the Arduino BSP source code that came with the QP framework to accommodate all the digital ports I am using, then drew the UML statechart for the intersection controller. And it worked. Better yet, developing this was fun.
The combination of QP and QM gives me confidence that it's easy to make the intersection controller much more advanced: eastward vehicle detection separate from westward, independent pedestrian crossings, dynamic timing (based on flow of vehicles), and more. The limitation is the number of available Arduino pins.
Would you look at the requirements I've written up for the intersection controller, and see if I am missing any? I'd like to make this set of requirements pretty thorough, as the more requirements there are, the more flexibility the students will have for what to test. If you have some suggestions, please post here or contact me any way you prefer!
Lastly, I want to thank Dr. Miro Samek, the author of QP + QM software. He's undoubtedly very busy, but he found the time to answer a question from me by email. Maybe someday I'll have an opportunity to use his great software in a commercial product!
Finally I got the motivation to sit down and learn its basics: I am teaching talented high schoolers this summer, and I am going to ask them to verify that a road intersection controller meets its requirements. I implemented this road intersection controller on an Arduino Uno using the QP framework. The sample code supplied with QP was a huge help for this.
Now I see how "tiny" the Arduino Uno is. I am using 10 of its digital ports. It comes with only 13, and I am leaving a strategic three unused because they're spaced so close to each other that some ports have to be skipped to avoid bending pins.
The intersection has four directions (N, S, W, E). Cars approaching from north and south have a basic stoplight without turn arrows. Cars approaching from west and east have a protected left turn arrow. And, all four roads have pedestrian crossing. The intersection "detects" a vehicle waiting in a left turn lane, just like in real life. It also allows a pedestrian to push the crosswalk button. (In reality this means that there are two pushbuttons wired to the Arduino: one for left turn, one for pedestrian crossing.) These two are the only events the Arduino processes, since only two digital pins can have an interrupt attached to them. The remaining ports are wired to LEDs, to display the state of lights.
This was surprisingly easy to implement with the QP framework: I just basically enhanced the Arduino BSP source code that came with the QP framework to accommodate all the digital ports I am using, then drew the UML statechart for the intersection controller. And it worked. Better yet, developing this was fun.
The combination of QP and QM gives me confidence that it's easy to make the intersection controller much more advanced: eastward vehicle detection separate from westward, independent pedestrian crossings, dynamic timing (based on flow of vehicles), and more. The limitation is the number of available Arduino pins.
Would you look at the requirements I've written up for the intersection controller, and see if I am missing any? I'd like to make this set of requirements pretty thorough, as the more requirements there are, the more flexibility the students will have for what to test. If you have some suggestions, please post here or contact me any way you prefer!
Lastly, I want to thank Dr. Miro Samek, the author of QP + QM software. He's undoubtedly very busy, but he found the time to answer a question from me by email. Maybe someday I'll have an opportunity to use his great software in a commercial product!
Friday, June 8, 2012
Philip's Subversion Quick Start
Another week, another one-page Quick Start. Today it's a quick start to Subversion and TortoiseSVN. Enjoy!
Wednesday, June 6, 2012
Awesome vs awe-inspiring.
It's too bad that the word awesome has become awfully diluted. Even its intensifiers are abused and don't add meaning.
Fortunately awe-inspiring still has its dignity: is longer, harder to say, and thus is not yet overused.
Fortunately awe-inspiring still has its dignity: is longer, harder to say, and thus is not yet overused.
Subscribe to:
Posts (Atom)