Developing Upwards

This is a two part posting, hopefully. The first part is a request from me to my Rails-using readers. (Do I have Rails-using readers?) Can you leave lots of comments telling a non-Ruby guy like me what importance the Rails/Merb merger I've been hearing about means for the wider web developer community?

I recommend purchasing Expert Python Programming, by Tarek Ziadé . I am extremely disappointed in this book, but I'm recommending it specifically if you already have a good grasp of Python. You see, I was really looking forward to recommending this book. I had hoped that the many people I know with a good developer head on their shoulders, but had not approached Python with seriousness before, would find this a perfect introduction to sit down with. While I'm really pleased with the writing and structure of the content, I'm afraid this is a book suffering from severe editing oversights. There are subtle mix-ups in terminology in many places and some code samples that are simply and absolutely incorrect. This is where I made my decision: >>> from threading import RLock >>> lock = RLock() >>> def synchronized(function): ...     def _synchronized(*args, **kwargs): ...         lock.acquire() ...         try: ...             return function(*args, **kw

This is not a bug. I traced the book meme that is going around back to this guy . My nearest was The Best Software Writing . Somehow, I really like what this random peek into a book gave me to post. Somehow quite fitting. The rules for this meme thing are : Grab the nearest book. Open it to page 56. Find the fifth sentence. Post the text of the sentence in your journal along with these instructions. Don’t dig for your favorite book, the cool book, or the intellectual one: pick the CLOSEST.

The week has been giving me little time to write, with lots of things to run around and do. I'll be waiting on my auto work to get done tomorrow and have more free time going forward. This blog a day thing has been difficult to do with any value so far, but I'll make it all average out. Anyway, I'm cheating today with a preview. This is a list of things I will absolutely be writing in the coming weeks. How To Understand AppEngine Datastore Under the Hood - Part 3 (by request) At least one new "How To Test Django ..." post Per chapter reviews of the exciting new book, Expert Python Programm ing by  Tarek Ziadé . For now, please check out this free chapter ! Announcement of a new project many people are aware of to help guide both new and moderate Python developers See you 'round the tubes.

I voted. Being a geek, I took a keen interest on the touchscreen voting machine used in my county. There was a checkbox within the larger label for each option. This kept everyone safe from the common "finger slip" mistake that has plagued the touchscreen voting machines. I also took note of a window along the side, where I could watch my votes being recorded on the paper receipts. I feel pretty confident most voters will completely ignore this physical verification. There were some parallels I drew between this and a recent interest of mine: touch screen interfaces. Voting machines might make us angry every few years, but mobile phones and PDAs annoy us each and every day. We're reaching a critical point in the cheapness of touchscreen displays, making them the inevitable first-class interface. We need to come to some standards and practices that give them the consistancy and expectedness that we get using our common interfaces today. At the same time, I'm glad to se

So I've had my G1 for about a week now and I'm happier with it every day. There are still some issues I have, but none that are related to the most important piece: the Android operating system. I love the software available and new things come at a decent pace. There are some network issues, but limited to my particular side of the apartment complex. I don't know anywhere else in town that I don't have good coverage. Interestingly, to me, my favorite application is Bubble, a basic bubble level app that works vertically or horizontally or to test the level of a surface. I don't have a lot of use for it, but it highlights some of the things I like most about open, portable devices. I imagine a real reduction not just in the number of devices I need (I'll be selling my iPod soon) but just the number of things, period. Now, I have felt like there is a lack of games for the system. More, that the games there are have been pretty much feeling like prototypes pushed t

So,  the   recent   interest   in   National   Blog   Posting   Month  has made me shift gears from NaNoWriMo to, obviously, posting once a day every day this month. Obviously, I missed the first, because I was out of town. I could have managed it anyway, but the change in plans was late in the game and I was out late that night. This still gives me a chance to flex the writing muscles and I'm really happy to take part in it. Thanks to everyone who has inspired each other to keep this going this month. This is my semi-mandatory and semi-cheating meta-post about the month, where I get to say I posted for the day. Really, I'm just filling time by writing about the fact that I'm going to be writing. To give this emptiness a little meat, I'll say that I have something of a schedule. I have a few topics to be covered in some fun posts and even somethings to cover in a series of posts. It will be a fun month. Everyone, keep me honest. Yell at me if I miss a day.

This week hasn't been great for my productivity. It has been a series of days overshadowed by a series of things coming up. Between standing in line at the DMV , computer issues, and today helping my brother-in-law with a very sudden move, it feels like typing is an unfamiliar act. (Unless its on the T-Mobile G1, which I'll be reviewing this weekend.) Today, I helped load a seventeen-foot U-HAUL truck, made a few last minute stops, drove said truck just over an hour south and helped unload it into a storage shed. I've never loaded and unloaded a complete truck in one day, in all the several moves I've made over the last years. I was always able to stretch them over two days, with a nice sleep in the middle. After all that, I had to drive the truck back to drop it off. I barely made it. My dear wife hit traffic on her way to pick me up, so I sat and I waited. I listened to the mechanic at the drop-off location declaring how "North Carolina is McCain country," w

Just let these guys do it for you. My hats off to them for this contribution to the community. It is much appreciated and will find use quickly, I'm sure. I know I have some room for it in my toolbox. Hopefully, the changes will be taken back to the 2.6 line so that any bugfixes that come will help stock Python and the backport. So, if you don't follow 2.6/3.0 development you might not be aware of multiprocessing, the evolution of integrating the pyprocessing module into the standard library. It was cleaned up and improved as part of its inclusion, so its really nice to have the result available to the larger Python user base that is still on 2.5 and 2.4. Although some edge cases might still need to be covered, the work is stable quickly. Here's an overview incase you don't know, so hopefully you can see if it would be useful for any of your own purposes. I think, starting out, there is more potential for this backport than the original multiprocessing module. Thus, I

This is how to review Memiary in 5 easy steps: Forget what you did yesterday. Check! Decide that all problems can be solved not just with software, but by adding new software just for that purpose. Check! Get written about on the popular ReadWriteWeb so people find you. Check! Be nifty enough to grab someone's attention when they try out the new service. Check! Surpass a plain text file in convienience, flexability, privacy, and install base. Damn ! Maybe next time. The best way to solve a problem is to avoid needing to solve it in the first place.

Yeah, AppEngine has been around for a while. That doesn't make my general AppEngine article less timely. Hey, I don't just write about stuff because its hip. In a few months, I'll announce what Google Chrome means for the web landscape. Seriously. Although a lot of people believe Google App Engine is a very big thing and extremely important to the landscape of the web, I get the strong impression from outside the camp that its more of a toy, and I want to address that. As with my quick review of App Engine itself, its hard to make real calls when everything is still beta, but we're working with what we've got here. The people who see the real potential of App Engine feel it and the people who just think its neat Just Don't Get It . What is there to get that so many developers are missing and why would those of us that do think its important enough to be evangelical about, as I'm doing right now? Once again, making any claims or arguments in this discussion h

In Part 1 I wrote about my method of testing the actual tag function for a custom Django template tag. I said I would follow it with a Part 2 on testing the rendering of the resulting Node . This is that follow up post for any of you who were waiting for it. Testing the rendering poses some more problems than our little tag function. Rendering is going to do a bit more, including loading the templates, resolving any variables in question, doing any processing on those results (like looking up a record from the database based on the variable value), and finally populating a new context to render the tag's template with. How do we test all of that, without actually doing any of that? This is the goal we're reaching here, for unittests. We want each test to be so specific that we test what something will do, without actually relying on those things it does. We aren't testing any of those things, just that our render() method does them. What can we mock easily? get_te

This is an index of different articles I've written covering techniques for testing specific software components. The number is small, but will grow in time. Initially, expect a heavier lean towards Django topics. How To Test Django Template Tags Parts One and Two

I'm involved in a project that has gone for a long time without tests and everyone involved knows tests are rilly rilly important . There is a point where acknowledged best practices simply meets the reality of the development mind and it doesn't always work out like you'd hope. We know tests are important, but we need to resolve this ticket right freaking now . You understand. The point was reached that this just couldn't continue and the costs of fixing the same bugs over and over were way too obvious to ignore. Tests are now popping up for things we're fixing and new things we're writing. As it happens, I came across my first real need to create a custom template tag. Of course, I wanted to test it. So how do you test something that is so entrenched in the Django processing pipeline as a template tag? Incidentally, I'm just going to assume you either know all about testing and Django template tags or you can follow along just fine. Testing breaks

So, this was going to be a post about the Python module, subprocess. I'm a big fan of subprocess and there are a lot of problems that are easier to solve by using it. We reduce thirteen distinct facilities into one class. We reduce a diverse ecosystem of interfaces into one, uniform interface. The subprocess module is good, both by itself and as a symbol for what Python stands for. I won't be writing my original post about subprocess. It isn't that subprocess isn't important, or that I don't think I can express myself properly, but that it brought up something else I should write about right now: What should I write about? Is this a blog about software development or is this a blog about Python development? Does it need to be only one? I'm looking for my direction here. I'm not going to stretch this out, because if I do, you won't read it . And truth be told, I want you to read it. I want you to enjoy reading what I write. At heart, I am a writer. I take

We learn to recognize a bad bit of code quickly as our code-fu grows. Arbitrary side-effects smell badly and crazy one-liners frustrate us. It becomes easier to identify what lines of a codebase you might want to clean up to improve the overall quality of the work. There is a line between codebaess with bad code in them and bad codebases. When do we learn to recognize this and what are the signs that the problem is far reaching, not localized? A bad codebase is an expensive codebase. It is difficult to work with and difficult to collaborate with others on. Identifying what makes a codebase bad is key to knowing when, where, and why to improve it. Improving the overall code quality reduces the overall code cost. I'm thinking about software in economic terms these days, and I'm hoping we can turn the recession to our favor by pushing the mantra Bad Code is Expensive Code . Costs of code come from three actions. Adding features costs, fixing bugs costs, and understanding costs. Ad

If you haven't yet read the first part of this series, feel free to start from the beginning with Part 1 - An Overview of the Underview Every AppEngine developer is familiar with the module. In Part 1 I introduced what goes on under the hood of this API, to give everyone a better understanding of what they are taking advantage of. Now, in Part 2, I'm going to detail the actual API that is used to utilize the raw entities behind our Model instances. At this time I am unsure if anything in this API is suspect to change, but I doubt anything is subject to drastic flux and I'm fairly confident everything here is safe for actual use, as much as anything else in AppEngine. Module: google.appengine.api.datastore Our main focus here is the Entity class. Everything supports it, from the Get, Put, and Delete functions to the Query class. Their uses are obvious. As previous exposed, each entity is essential a property bag and will take any given properties to the datastore for storag

There are a lot of wrong perceptions about the datastore in Google AppEngine. People both familiar and foreign with AppEngine don't really understand what the datastore is. There is a deeper system underneath the nice API we are given. Understanding the guts can help us understand the skin. We may also find there are times when we must shed the skin for new clothing. The biggest misconception about the datastore is the assumption that "kinds" are anything like "tables". You could use a set of entity kinds similar to the way you would use a set of tables, but they simply are different beasts, entirely. A table controls a strict requirement on the structure of its rows. Every entity, on the other hand, is free to hold any properties of allowed types. The published Model API is all an abstraction provided to give us a nice interface on top of an otherwise much looser foundation. Many people would be very surprised to learn that a given kind doesn't actually req

The aftermath of the quakes in California saw a lot of talk about Twitter getting the word spread, from the trenches, very quickly. Chris O'Brien heralded it as a sign that NextNewsRoom is doing something right. A lot of people were talking about it. Twitter carried the news before any news agency. First is one thing, but quality control is something else. The flood of messages reached a point that its almost assured no one read every quake tweet that was sent. There were just too many of them. Can anyone imagine the flood that would have been seen if Twitter existed and was popular on the morning of 9/11? It would have been maddening. We can take this situation and ask two questions. How can we form something better from the flood of tiny messages? Do we even want to? Can we find some way of filtering both relevant and "good" posts and could we pull some larger picture from all the little pieces? Of course, doing so would take resources, and those are either iron, eyes

Most of the buzz about the App Engine has died down, except among the developers actually using the platform. When the first public announcements were made, I was a part of the original group of developers first given access. This privilege was wasted. I did nothing with it. This has changed, which is a topic for a different post. I thought I'd take a moment to make my mark on the "What I think about Google App Engine" wall. A proper review is difficult, for a number of reasons. Namely, there is a very vague understanding of the difference between this "Preview Release" and what we'll have when it launches with all official status and commercial potential. We can only hope that any big changes won't interfere with our existing applications. If that does happen then existing players might turn to AppDrop for help, although any mass migration is highly doubtful. In any case, what everyone is talking about is what App Engine is now , not what it might turn

So, the twittersphere is in an uproar about those dropped follower counts. Is everyone more afraid of the lost high-count vanity or that so many people follow without thought that we might never regain many of the legitimate follows? Either way, there is a lot of complaining about the apparently service mishap from the company that we shell over so none of our hard earned dollars to. The mistake is one thing, but I see quite a bit of sentiment against the very method they undertook to combat the spam problem. I challenge that claim, because I think they're on the right track limiting follows, and I'm going to explain why. For Popular People This Means... You're popular by how many people follow you, not the other way around. You can go on your way, with thousands of people hanging on your every toilet flush, and Twitter can still limit those damn spammers from following you along with ten-thousand other ego filled, txt-fingered masters of the twitterverse. For "Communi

Atul writes: Last week, Scott Petersen from Adobe gave a talk at Mozilla on a toolchain he’s been creating—soon to be open-sourced—that allows C code to be targeted to the Tamarin virtual machine. Aside from being a really interesting piece of technology, I thought its implications for the web were pretty impressive. The next steps Scott took are the most interesting, because he starts using this to build stock Python and Ruby runtimes that are hosted on Tamarin. This is a fascinating solution to one of our biggest itches: more languages on more platforms. Imagining the sheer number of languages (most) this opens up to running on any Tamarin run-time (Flash and Firefox 4) is mind boggling. Go on, let your mind be boggled. Combine this with the basic idea being targetted to other platforms and you've got a lot of possibilities. Target other bytecode, like Java or .Net, and you open up more possible cross-builds than you can count. Platforms begin to fade on the borders. At the same

I couldn't even pluralize "dominator" because Nintendo won't let Sony in the door. Nintendo has the handheld game market locked tighter than Fork Knox. This won't be the first place to call out the "Apple is entering the handheld gaming market" flag, but I do think I can lay out the steps they would (or should) take that can lend credibility to the idea. If nothing else, I hope someone there is reading. Apple can't do this alone, but they have a very good friend in another company with a name that starts with A: Adobe. The pair would be the ultimate contender into the very tight market and the approach is amazingly simple. Flash is coming to the iPhone and iTouch, and I'll hope they make bookmarking Flash games easy and give us the option to "fullscreen" them on the devices. Explicit offline caching wouldn't hurt either. The next step is obviously to allow flash apps and games to be installed directly for quick access and immediatel

This is my dream so don't squash it for sounding trivial. This is my window to the world, the tools of my job, and the outlet of my creativity! I want the Perfect Keyboard and the Perfect Mouse. Operate as NiMH battery chargers when plugged into USB for power Lighted keyboard to type in darker conditions. Must be adjustable Must be configurable to PC and Mac layouts Would be handy to configure to DVORAK layout, as well Retractable USB cables Keyboard functions as USB hub, even wirelessly Scroll ball instead of a scroll wheel . I do love my Mighty Mouse Weights for mouse, with storage in keyboard Trackball (or even a nub) in the keyboard to lean back and browse with Splittable keyboard with locking adjustments I am going to spend the rest of my life replacing perfectly good keyboard and mouse combos if no one solves this simple list of requirements. The adjustable keyboard is probably the hardest part, combined with the other requirements I want fit into it. I'd like to pull th

Twitter does a lot of queuing. I mean, a lot . We know other people have a need for some good queuing, so much that Amazon even released Amazon Queue Service, not so long ago. There has never really been a common queue server, and maybe that is because its so simple that no one has really had the need to push one hard into the public eye. At least, as public as our eyes are. Enter Starling, the internal queue system of Twitter, recently released to the public. Written in Ruby, and I don't even mind! Pointed there by my ever-pointing buddy, David Novakovic, Starling does nothing absolutely remarkable, but someone has to get the light. What is interesting is their choices. Starling uses the MemCached protocol, so your clients are probably already prepared to use it, they just need to treat the queues a little different from the mappings. The typical MemCached get-operation now removes the item from the queue. The keys function is identifiers for the queues. I don't think it could

So I vowed to write more and blog more and the year has plenty of time left in it, so don't worry about me. The past month has been amazing, and that's why I haven't had the time to write. I'll be scheduling it soon, so a resurgence in content is imminent. I try to keep on my tech topic, but I do far too little activism on the things I believe in, and its high time I changed that. Don't worry, politics will not become a staple of this blog, but I'm likely reviving my personal blog. But, no one reads that, so how vocal can I be about something with no readers? Today is Blog for Choice Day We're supposed to be a logical bunch. We spend out careers thinking about things and being intelligent. When you think about something long enough, there are obvious realizations that everyone comes to. People that think about tracking version changes all realize you need goof version control. Any group of people trying to coordinate understand the need for issue trackers. S

This is a follow up to my first How To Walk Backwards to HTML 5 article. The one comment I got in this first Twenty-Four hours pointed out a lack of explanation on my part for a few things. I know about the current HTML 5 specification. I've read most of it, reviewed plans and others' reactions, etc. My views on HTML 5 are not out of a lacking of knowledge, but are a reaction to my knowledge of HTML 5. I think what HTML 5 looks to be shaping into is the wrong direction. The creation of the layout specific tags is a response to what was coined "div hell", but it isn't the right solution. We all have different needs for what we need HTML to represent and it gets abused into representing everything from resumes to tetris clones. Abandon schemas and doctypes and just let us write the tags that have meaning for our cases. Hey, we can do that with XML namespaces! Give us to the tools to discover formatting and layout rules and control the pages intelligently. If you ne

So this is my obligatory start-of-2008 post. I know I haven't written much lately, but work was busy and then there was the holidays, and I'm making a commitment to really revitalize my blog. Part of that may be that my adsense, after years of blogging, as only hit half the required minimum balence for payment . But, I'm not in it for the money. Not unless there was a lot of money in it! For 2007 this means... that I need to wrap up the last year We moved back to North Carolina when the Pennsylvania winter cleared up, and I'll admit that the summer was a bit rough. I lost my most steady contract when funding went sour, shortly before the movie, but you know what? Staying home with the family was great without a lot of work to be done, and we got by OK. I enjoyed the time. After a while, I started CharPy, the Charlotte Python Group. We're still small and growing, but the first meeting gave me a lead on a full-time position at SocialServe.com, where I'm now happil