The Arduberry is an Arduino that sits on top of a Raspberry Pi. It connects to the GPIO pins. You can’t see it in the photo, but there is a MEGA328P chip mounted on the bottom of the board. Functionally it works the same as what would happen if you were to hook an Arduino Uno to a Raspberry Pi using a USB connection. By running software like Firmata on the Arduberry and appropriate libraries on the Raspberry Pi, you can send information between the Arduberry and Raspberry Pi.
So why would you want something like this? There are many shields and sensor libraries available for the Arduino family. Also the Arduino provides analog, digital, and PWM pins while the Pi only has digital pins and a single PWM pin. On the other hand, the Pi has significantly more processing power, audio input and outputs, and allows you to use programming languages that aren’t available for the Arduino. For example you could run Scratch, Java, Python, or Racket on the Pi and use it to control the Arduino.
By default the Arduberry is powered by the Raspberry Pi and since it sits on top of the Pi, it has a nice small form factor. The downside is that if you want to use the Pi to upload programs to the Arduberry, you have to be aware that it uses pins 11 and 13 to accomplish this. So if you have anything plugged into pins 11 or 13, when you try to send a new program to the Arduberry, you’ll get an error like this:
avrdude: The AVR device is not responding
avrdude: initialization failed rc=-1
Double check connections and try again, or use -F to override this check.
So for example if you try to use something like an Arduino Motor Shield that uses pin 13, you’ll have to remove it to upload a different program to the Arduberry. If you have an LED plugged into pin 13, you’ll have the same issue until you remove it.
So the Arduberry can be a good choice when the Arduino code is going to remain fairly static or you don’t need to use pins 11 and 13. If you are needing to make a lot of changes to the Arduino code and have a shield that uses pins 11 and 13, you may be better off with a normal Arduino connected with a USB cable.
The Raspberry Pi has normally been too slow to run DrRacket. The new Raspberry Pi 2 is quite a bit faster, but if install racket from the default repositories, you’ll probably find that you can run racket, but DrRacket fails with a message like:
Seg fault (internal error) at 0xb0f5b0
SIGSEGV SEGV_ACCERR SI_CODE 2 fault on 0xb0f5b0
My guess is that this as something to do with the switch to ARM7 from ARM6. If you try to build Racket from the source, you may get an error like this:
Makefile:155 recipe for target ‘install-3m’ failed
make: *** [install-3m] Error 137
make: Leaving directory ‘/home/pi/Downloads/racket-6.1.1/src'
Makefile:86: recipe for target ‘install’ failed
make: *** [install] Error 2
Best I can tell this is an out of memory error. You can probably get it to work by rebooting and making sure there are no other programs running while you do the build. Also you can start the machine without launching X windows to leave more memory available.
I was on a video conference and chat room today. Someone on the video conference asked what to do about some issue with management. At few minutes before someone had typed into the chat window asking how to delete tasks. I responded with, “You have to kill them.”
My chat popped up on everyone’s screen right after the management question. The person talking on video conference said, “Well, Mark, I suppose that is one option.”
A sign that said “Park Courageously” inspired me to park like I had never parked before. Turns out it actually said “Park Courteously.”
Mark Shead has worked as a system administrator, network administrator, IT director, and software engineer in variety of industries. Currently, he works with startups and on startup style projects within larger organizations. His focus is on getting better business results by improving software engineering processes–paying particular attention to the human element. This includes helping teams follow Agile principles, using DevOps to drive the delivery of business value, and engineering process improvements.
(Posted here so I can find it again next time I need it.)
Years ago when I was taking a typing class, there were certain tests that were designed to test speed not accuracy. It didn’t take me long to realize that, since there was no detriment to making mistakes, the logical action was to mash on the keys in order to get 700 words per minute for that type of test.
Some IT organizations design their issue system to focus only on the speed of closing issues and not on accuracy. Working with these organizations gives me a lot of empathy for how the typing teacher felt when I turned in a page of random letters and got the highest score.
Agile is a set of principles for creating software. It doesn’t prescribe a specific methodology. So Agile says, “it is good to reflect on how things are going,” but doesn’t say specifically how to do it. Scrum and Kanban on the other hand are methodologies or frameworks for doing the actual work.
Scrum was created out of Agile, while Kanban comes originally from systems developed by Toyota for managing assembly lines starting back in the 1940s. Scrum is based around iterations while Kanban is based around flow. An iteration in Scrum might be a week long and start with a planning phase where the stories for the iteration are selected followed by development and end with a demo and retrospective. These iterations are typically called sprints. The idea is to get a cadence of a set of features being delivered on a regular basis–typically 1 to 4 weeks. The amount of work that can be in process at one time is limited because the number of stories committed to in an iteration is limited.
Kanban’s focus on flow is more concerned about moving stories through to completion smoothly. There are no iterations and work is limited based on the work in process limit placed on the different types of work. So the development column on a Kanban board might have a work in progress limit of 4 which means the team can’t pull another story into development until something gets pulled out of the development column. This is done to make sure that stories flow through the system and don’t get backed up in front of one resource or one type of work. The people responsible for work in one particular column pull in work from the column to their left when they have capacity. This ripples up stream as columns get an empty slot and can pull from their upstream column. In effect, one story being completed sends a signal up stream than another story can be pulled off the backlog and have work started on it.
Scrum has a Story Board with cards moving across it. Kanban has a Kanban board. Both look very similar, but the way they are used is very different. In Scrum the Story Board is a visual representation of what is being worked on where. In Kanban it is a visual representation, but also a control mechanism to manage the flow of the work. It controls how fast work is released from the backlog. In Kanban, it would be common to create another column to start gathering metrics whenever the team finds some type of impediment. That wouldn’t normally happen with a Scrum Story Board.
For an analogy of the differences between Scrum iterations and Kanban’s flow, you might think of Scrum as being similar to carrying a bucket of water between two points. The water represents work and the bucket represents the iteration. In Scrum you take the bucket to the destination and then talk about how you could do it better, then go back and do it again. Maybe this time you use a slightly different sized bucket, etc. Kanban is more like a gutter running between two points. You pay close attention to any areas that start backing up the water and make sure you don’t pour more water in than is coming out the other end to make sure it doesn’t build up and spill at a curve.
The team I’m currently working with is using Kanban so we have continuous flow for the development. However, we still use iterations for things that can benefit from a cadence–most notably the demos and retrospectives. We also continue to have daily standup meetings. So basically what we’ve done is removed the iteration based work from scrum and replaced it with the continuous flow of Kanban while still keeping the other parts of Scrum.
I’ve heard some people refer to this as Scrum-ban. I’m hesitant to use that term because it sounds silly to me…but I suppose no more silly than Scrum or Kanban.
In Greek mythology, there was a goddess named Eos who fell in love with a Trojan named Tithonus. She asked Zeus to make immortal and Zeus did.
In a different myth, the god Cupid pricks himself with one of his own arrows and falls in love with a mortal woman named Psyche. Eventually they work through all the issues with the mother-in-law-to-be and Cupid makes Psyche immortal so he can marry her.
So both Tithonus and Psyche became immortal, but there was one small but significant difference. Tithonus was made immortal by Zeus who wasn’t really bought into the outcome and was just completing a requested task. Psyche was made immortal by the god who wanted to marry her. Psyche never died and never aged. Zeus left out the never aging part with Tithonus. Tithonus became so decrepit that his wife Eos eventually turned him into a grasshopper.
There is a huge difference in what you get when someone is just completing a task and when someone is really vested in the outcome.
If you are using a Redhat 6.4 AMI EC2 instance on Amazon Webservices and after a reboot you can no longer connect to SSH, this might help you. There appears to be a bug in
/etc/rc.local that tries to add the same lines over and over again to
/etc/ssh/sshd_config. Here is what the problem looks like in
cat <<EOL >> /etc/ssh/sshd_config
Everytime the machines startup it is going to append to the file and eventually SSH will stop coming up correctly. You may want to delete those lines or at least modify them to do something that you want them to do.
Also before you reboot take a look at
/etc/ssh/sshd_config and make sure it looks right. You may need to delete some of the extra entries from the end. You can test it by doing a:
sudo service sshd restart
sshd_config is bad, this will fail to restart sshd, but it should still leave you connected so you can change the config and try restarting it again.
If your machine is running but you can’t connect to it, you can disconnect the the volume, mount it on another EC2 instance, change those files and then put it back on the original instance and start it back up.