Earlier this year I ran a few tests comparing a Raspberry Pi (rev 1.0) to an Amazon AWS Micro instance. There were a few interesting and insightful comments in response to the post. I want to run through a few of the open comments and questions in a second post.
What about an AWS small instance?
The most common piece of feedback I received was that I should have used a small AWS instance. I know AWS well (I work for Amazon) and I know the micro instances are capped. I chose a micro instance based on the price. Let’s compare a small and micro instance.
I have had some downtime over my Christmas holiday which I have used to pick up Python via Codeacademy. Codeacademy offers several free courses (they call them tracks) and their Python course is pretty good overall. I have finished about half of the Python track and want to share the three strengths and weaknesses of the Codeacademy Python course.
These are the three best things I’ve discovered running through the Python track on Codeacademy.
- The lessons assume you have no experience, which is great for beginners – no previous programming required.
- You needn’t download anything – you can write and run code directly on the Codeacademy website.
- The lessons are broken into pretty small chunks and are very easy to start/stop based on your schedule.
These are the weak points, in my opinion, of the Codeacademy Python track.
- Sometimes the online intrepreter does not recognize a workable solution to a code problem – in some cases you need to tweak your solution in silly ways to “pass” the lesson.
- The lessons sometimes repeat content – while this may be useful for novices the lessons can get tedious if you have experience with other languages.
- If you know other languages, this is likely going to be the slowest way to learn the difference between what you already know and what you’re learning (again, this course is geared and likely great for beginners).
Overall, the Codeacademy Python track has been useful and I think it’d make an excellent starting point for anyone who is new to Python or programming in general. If you’re thinking about learning Python (or how to get started writing code) I’d recommend you check it out.
Traditional progress bars annoy me a bit. While a visualization of progress is nice, the traditional progress bar misses one important component – an indication of velocity. I know, from a programming perspective this tricky because velocity is variable. In my mind, however, the progress bar control should be able to calculate its own velocity based on the updates it’s receiving. I
may just be am really anal but I would like to know if the progress bar is being called to update, even if it’s very slow progress.
Enter, the velocity bar.
The basic idea is the progress bar shows some sort of visual indication representing how often and how much it’s being called to update. Users could see if the bar is really moving or is actually stalled.
Now that I type all of this, the next level of this idea would be some sort of decentralized reporting system where velocity bars inside of a specific application ID could report their update profile. In turn, future velocity bars from that same application could gather the “average” update profile to report on whether the application is moving faster/slower/same than normal.
Just an idea.
This is going tobe a quick rant.
In my line of work, I deal with a couple of vendors who have sold my employer .NET (ASP 2+) applications and utilities (both of which are usually written in C#). I appreciate the fact that .NET makes a lot of stuff pretty quick, trivial and really maximizes the time of each programmer using it. Also nice is the fact that .NET works well on any machine with .NET installed (and even in some cases, Mono).
What annoys me is the fact that programmers, I think, often rely on the fastest and least efficient solution instead of looking at the problem and finding the best solution.
For instance, one application with which I am working puts out a huge (200MB or so) XML file. Problem is, the data source which is the “feed” for this XML has some quirky data which results in elements/nodes needing to be removed. The vendor “gave us help” and provided a utility which strips the bad stuff out but it also reads the ENTIRE XML file into memory. Based on what is happening, it looks like they are using the XmlDocument class.
Yes, that class is useful and I am sure it’s useful to have the whole XML file in DOM and in memory. It’s really bloody inefficient, though. Yes, it’s simple to use but the compiler is doing a lot of complex things. Instead, my solution:
- Open file
- Read line-by line
- Look for bad data
- Keep track of where “it” is relative to the current element
- If the element is “OK” flush it to a temporary file
- Overwrite the input file with the temporary file
All said and done, it takes about 1/3 the time and about 1/30th the memory. Plus, the vendor hard-coded the items “to look for” in the application. Seriously, using an App.config file is trivial in .NET 3.5 and there is no reason this should not use 3.5 since it’s a stand-alone console application.
Just because it looks simple to the programmer does not mean it’s simple for the computer, too.