Posts Tagged ‘PythonShop’

The PythonShop saga continues

Monday, January 28th, 2008

We made a lot of progress working on our python shop this weekend. Our working patern ended up being a pair programming scenario, with him at the keyboard (as he was the python person, this was the most efficient) and me finding logic problems, and working on the overall program design. Based on some of what I’d seen discussed recently on the Alt.Net list regarding validation, we ended up doing a close-to-the domain style validation. The classic TurboGears way of data validation is to attach it to the page methods inside the controller. In contrast, the Alt.Net discussion centered around how domain logic validation (for instance, object x should have an object y to allow a certain set of actions, and this integer should not allow things outside of a certain range, and certain fields should be required) should be usable with the business objects themselves. If this is really domain logic, that is something that gets changed by the client, should be in one place and should be reusable no matter how these objects are addressed, bet it in other forms in the application, future tests, or even command-line manipulations. In a more advanced scenario, we could even have different object validators that we inject as appropriate… since this project is a toy 5-table project, we considered that, and decided that was out of scope. But to bring that object validation logic into the domain, we ended up working an optional validator method into the business objects.. We still have validation in the controller to deal with the form, but it purely tests for formatting of input… for instance, numbers should be numbers, to make sure that any data that makes its way into the object at all at least is the right type so the validator there won’t throw up trying to compare a text string to a decimal or something. The only negative of this is that it ends up being a two-pass validation, (type formatting then business validation) but it seemed like an acceptable tradeoff.

Python, the other white meat

Tuesday, January 22nd, 2008

So, a colleague and I started on a little project. We’ve decided on our own time to take a toy project and jointly try it out in as many languages as are interesting to us. It’ll be a great learning experience, and it’ll also be some nice code that can be shown off without nondisclosure-type strings attached. We’re an interesting team because he’s heavily a Python person, whereas I’m mostly .Net. We’ve decided upon a shopping cart as our model project.

Our first session was to determine a general design/scope for all of these little shopping cart projects. An hour or so later, and a paper full of boxes and arrows, and we had a rough first hack at the sort of model that Amazon must have. Upon looking at it the next day, we decided that we’d gone though some temporary insanity. For the type of toy project we want to build, things like coupon codes, order fulfillment and tax were way out of scope! Really, a simple 5 table design was plenty for experimentation, and more than that would be too exhausting to realistically get through multiple projects.

Our first project is in Python, which you might think would be boring for my python-specializing colleague, but we’re doing it using TurboGears and SqlAlchemy, which are both new to him. I’m working my way through learning Python basics and finding some interesting differences from C#. The passing in of self everywhere as a parameter is odd, especially in that you only have to declare it, but not really pass it! I also found the importing of not just namespaces, but of actual classes (sort of as a shortcut) to be fairly weird. the dynamic number of parameters to functions was interesting as well… in C# you’d have to handle that as a passed-in array, list, or dictionary, and those things really wouldn’t be full-fledged parameters. At this point, he handled the initial TurboGears setup, and I’m looking through the default login stuff. Some of the initial setup was a little odd-I mistakenly tried setting things up in Windows before throwing that all out and giving it another go as a full cygwin setup, which worked a lot better! Hopefully, by the end, he’ll have a good grasp on TurboGears, and I’ll have a decent beginner’s grasp of TurboGears and Python! The SQLAlchemy stuff looks to have searching capabilities that are similar to some of what nHibernate has with its Criteria tools. (which, admittedly I haven’t looked into much-I’ve pretty much used HQL thus far)