| Home | Blog | Climbing | Mountaineering | Backpacking |
Hey guys,
So, I thought I’d continue this meme a little further. I got some great comments the last time. This resume idea is inspired by my friend who is staying with me while he finds a job here in Colorado. Ben’s an electrical engineer with 6 years experience and someone I trust with my life on a regular basis. Anyway, here is my circuit resume, “feedback” appreciated.
The OmniGraffle source. Oh, and here’s my “real” resume.
Hey guys, I’ve been busy for a bit, but I made up this new resume for the TG tour, looking for feedback if you’d like to comment.
cheers.
-chris
If you are from the US, you may be familiar with the custom of racing to your local commercialization hub before the sun rises and beating your fellow man over the head to get that cute little fifi doll your daughter wants for christmas. This endeavor is often fueled by the previous day’s binge on tryptophan-laced poultry.
TurboGears wants you to know there _is_ an alternative to this ruckus behavior. While it may not offer a method of transference of the latest flu virus strain, you may come hang out with the leaders of our community on irc://#turbogears@irc.freenode.net . and ask questions and help your fellow man. In the spirit of thanksgiving, you may decide it would be good to return the 1000s of lines of code contributed by helping us document that mess*!
November 27, 2009 starting around 9am MST, ending when Chris passes out, we will convene and work on the 134 todo items left in our documentation. If some of you are near Denver/Boulder that day, I would be happy to organize an on-site meetup, please let me know. So, the day after thanksgiving, why not act gluttonous for one more day (with your writing) and lets see if we cant close another 60 todo Items as we did on the last doc push. Be you an advanced super 37173 user, or someone completely new to TG, we have got something for you to do! Lets work together to make the formal 2.1 release of TG the best yet, with the highest level of completed documentation evar!
cheers.
-chris
* the term “mess” is not used literally in this sense.
It’s October again, and that means Open Source folks are meeting at Google in Mountain View, CA. Last year I had such an enlightening experience that I wanted to do my best to make it even better. One thing that I
have realized is that it is hard to participate in a conference without some free time. Your brain functions better if you arrive, settle in, get your bearings, and then start the real work.
On Thursday I arrived in San Fran, and immediately sprinted to the coast. I live 1000+ miles from the ocean, and although I see myself as a mountain person, there is something compelling about swimming in the cold surf, emerging with a layer of brine. After a few hours of work in a coffee shop overlooking the sea, I headed into the interior to meet with my TurboGears pals and get the conference started.
Friday Jorge and I toured San Francisco. We decided to rent some bikes an ride across the Golden Gate Bridge. I like this kind of self-guided tour, and we definitely got lost but had a good time in the process. We arrived in Sausalito after crossing the bridge, and grabbed a bit to eat before taking the ferry home. Later on we met up with Mark and the rest of the Google Summer of Code folks for some socializing.
Friday night we finally hashed out the json/return type challenges with TG. Sticking with 2.0 implementation, you may only return a dict from your controller method if you expect the normal TG rendering to occur. However, if you return an iterable object, the Pylons machinery will take over and stream your content. This represents a problem because if you return a list and set the exposed renderer to json, it will return your dict in string form. To protect the developer from making the mistake of creating a CRSF attack, this behavior will now raise a meaningful exception. Having Mark and Jorge around to make this decision definitely sped up the implementation.
Saturday we arrived bright and early at Google and got started with the conference. The mentor summit is a self-organizing conference, which means the talks are determined on the spot rather than pre-planned. More and more I am finding myself drawn to these types of meetings. They provide a much more interactive approach to conferencing as apposed to the eyes forward norm.
The best session I attended was Recruiting and Retaining Awesome People I had proposed a sprint-related session, and decided it would be best to merge with Donnie Berkholz since his session was similar in scope. After all, sprinting is just one concept in the scope of recruitment. We had a large number of attendees, and had to re-arrange the eye’s forward setup the room had because it did not allow for the discussion we both wanted to generate.
There was excellent discussion, and I took a few new ideas away from this session. To highlight a few:
Toxic People – Placing a label on a person as toxic can be dangerous both to the people involved in the labeling, and to the community at large. If you can isolate the toxic behavior and catalyze a new response from the person, someone who is viewed as toxic may then become a valuable contributor to your project. Don’t be quick to label a person unless they simply do not respond to requests for changing of toxic behavior.
Code Review – Providing prompt and complete code review is a reward for the contributors work. I think this is especially true in OSS where we write our code in a public domain, and are therefore expecting that others will look at our work. The work in OSS is more than just the final product, it’s the code itself. By providing feedback on a patch, pull request, or documentation augmentation, you are growing a potential long term contributor, even if your review is critical. Reviewing code allows you to set expectations for your code project so you can further mold the codebase to meet your organization’s needs.
Socializing – The modus operandi for most technical IRC channels is to focus closely on the topic. This keeps the signal to noise ratio high, but makes the room feel stale. By interacting with your users in a more personable manner, it’s easier to build the interpersonal relationships that are required for contribution longevity in a project.
Thanks to Toshio for taking such detailed notes for this session.
For some reason I was having a hard time being motivated by the sessions. It seemed odd to me that there were only 1/2 of the session rooms booked at any one time on Saturday. I discussed this with Jim Baker, one of my Python colleagues in Boulder, CO. He responded by providing a “How to write a Python Interpreter” session that was remarkably well attended. The group was a mix of Python users, developers, and those interested in interpreters in general. One of the session members was a major contributor to PyPy. It seems obvious to me that python is going to move to the next level soon in terms of performance. One of the things discussed was the usage of language constructs to provide the interpreter information about a class, method, module, in order to constrain execution and therefore provide faster execution. Consider the use of __slots__ in Python classes. If you know there are only certain attributes in a class, you have additional information that can be used by the interpreter to limit frame size, etc. This is great for memory limiting techniques. Now, apply this idea to performance techniques, and you can see that there are many opportunities to give the Python interpreter hints about execution that would allow it to do less work and therefore increase speed.
When I wasn’t participating in sessions, I was doing my best to share experiences, theories, etc. in the hallway track with other attendees. I was also working on the TurboGears 2.1a2 release. It’s funny, because our release process is more manual than I like, and therefore takes a few hours to complete, but if you split it up 10 minutes here, 30 minutes there, you can get a remarkable amount done even in the midst of something else major going on. I’m not sure if this time usage technique has any merit, but I have used it at previous conferences. It feels very easy to capitalize on the energy from the conference and get some work done, I’m not exactly sure why yet, but I’ll have to think about it some more. In any event, 2.1a2 is released and ready for testing/consumption. I think we are going to have 1 more alpha before we lock down the api. Mark wants to change lookup to _lookup, so we have to add that and deprecate, deprecate, deprecate.
Sunday was more of the same in terms of sessions, but the attendees seemed to step it up and provide some interesting topics. My favorite talk of the day was one regarding turning open source into a sustainable profession. A number of topics were discussed, but this general forum lead us to group open source financial success into three categories:
Software Product Licensing – Turn your OSS project into something that is salable, either by providing a pay-for layer on top, or licensing it in such a way that corporations are responsible to pay for what they use, still allowing the OSS developers to have their way without incurring the costs.
Sell Your Organization – If your organization can offer value to an industry, it is very likely that an industry leader will want to purchase the rights to that intellectual property wholesale. MySQL is the example of this that stands out in my mind the most.
Software as a Service – Consulting is one of the main ways developers can benefit financially from their work in the open domain.
I actually would like to explore a few of these in depth, and I think the next open-space conference I attend I will try and set up a session about at least Software as a Service to explore ideas about how to give away your software and thrive simultaneously.
Google continues to provide a valuable service to the community with the Google Summer of Code program. I am convinced their motives for running such a program are noble. One of the sessions I participated in was the Google Highly Open Participation (GHOP) session, and basically it was just an informative session for me. I wanted to know more about the program, and the result is that TurboGears will likely work with the PSF in the future to participate in this program.
One of the reasons I get a lot out of conference like the Mentor Sum is that there isa large variety of technologies in attendance. This moves me out of my normally Python-centric interactions with other developers. While I think that Python is the best way to express myself as a developer, it is also interesting to see how other developers solve similar problems in their own domain.
The ultimate sprint incentive would be for companies to put up a bounty to fix bugs, or otherwise provide support for an open source project. This is the toughest thing to sell I think, but if Google can do it, why can’t other organizations? I have seen this attempted in the past with mixed results. I think it was a half baked idea, and that we can do better than that. The challenge is metrics, and making sure that everyone gets their fair share. I mean, at that point, sprinting becomes payment for work done, the sprinters are just hired guns for a weekend.
I think the challenge has been, and will always be metrics. How do you measure the work and who did it, and how much is each thing done worth? I think the sprint organizer is the greatest asset in this situation. He usually has the best idea about what needs to be done, what has been done, and ultimately who did what quantity/quality of work. So you can use him as your metric definer.
My idea is this: A sponsoring company provides the OSS organization with a certain amount of money, and what they would like to see achieved in an organized sprint. This money is given to the organization as a donation regardless of the outcome of the sprint. The donation may also be given to the organization with no stipulation of task, but the sprint organizer must choose a topic of interest in order to guide the sprint.
The sprinters all agree to a set method for dissemination of funding provided by the sponsoring organization. My suggestion would be to split all of the funding equally, but in a capitalist nation, it is hard to justify giving the same funding for a person who did a little work on a piece of documentation vs. someone who spent 40 hours putting together a full tutorial. Another method would be to allow the sprint organizer to disseminate the funding as he sees fit, but the sprinters would have to agree to this before work is started. The work would have to be completed by a certain deadline to obtain the funding, because project organizers do not have time to track down who did what 4 months after the fact, it’s just not practical. Finishing a week after a weekend sprint seems reasonable to me.
I am sure to see lots of comments about these ideas because when money gets involved, everyone gets uppity. (one of the great ideas behind OSS is that there is no money paid for the actual software)
So, there exists possibilities for setting up a sort of Round-up style sprint. The goal is to provide sprinters incentive for providing bug fixes, or even to document a part of the code that is otherwise hard to get anyone to document. I would love to open a discussion about this topic, as I see it as a completely different business model when it comes to software development.
But you have to ask yourself, “What’s in it for the company?” Well, first I think you have to ask yourself why Google has been running programs where they pay for OSS development, no questions asked, for 5 years now. But here are some insights while you ponder that. The easiest reason to understand is that the sponsoring company has some bugs in OSS software they use that they need fixed, and a team of experts can fix them in a weekend, or their staff can submit bug fixes, go through the rigamarole of OSS contribution, and things get done in months.
The next less obvious reason for a company to provide funding for a sprint is that they are using OSS software that could use a little help in the documentation department. By paying for documentation, they are getting a cut-rate deal on the experts that usually created the software providing documentation for those things that may be crucial to their business’s success. This also reduces their dependency on any one employee who may have in-depth knowledge on a particular software package. By ensuring the OSS software that the company uses is well documented, the company ensures that the intellectual know-how for that piece of software remains with the project, not with the employee that may leave at some later date.
The last simple reason I can think for a company to sponsor OSS is for recruiting reasons. Typically the people involved in the sprinting process are the ones that know the most about it. It is also be a chance to evaluate an employees enthusiasm for work in general. Those who are sprinters are more likely to work well with others and stay with projects for the long haul, in my experience.
If software development is described as herding cats, gathering and directing sprinters is like herding stray cats. I once had a stray cat visit me when I was in my potato-tuna days, and I gave it some of my tuna, because it looked in worse shape than was I. And you know what, that cat always returned for the tuna. Now, I’m not much of a cat person (current cat count: zero) but I think that if software developers are truly analogous to cats, they might show up at your door once, but it’s much easier to get them to come and visit regularly if you give them some tuna once in a while.
A few weeks ago the Front Range Pythoneers decided to organize an “Uncon” where people show up to discuss various topics on-the-spot. This is the sort of event I really enjoy participating in, so I of course agreed to attend. At the same time, I was approached by the guys from Developer Day to do a talk on TurboGears. You can imagine the conundrum I faced, but thanks to the willingness of the DD organizers to be flexible, and some creative planning, I was able to participate in both.
Speaking at Developer Day was a new experience for me because I was talking to folks that were not necessarily versed in Python,never-mind TurboGears. The conference appeared to be somewhat Rails heavy, but it was refreshing to see organizers reaching out to the greater web community to provide a well rounded conference. The nice thing about speaking to a wider audience was that I was able to expound some of the history of the Python web, as well as describe TurboGears at a high level without worrying about boring the audience. I was quite nervous speaking at first, because I have not done so in a few months, but seemed to settle into a groove by the time I showed an example of how easy it is to inject repoze.profile into a TG application and provide a cachegrind display to find any slowdowns in your app. I hope that this example was able to express how versatile WSGI is.
I stayed the morning at DevDay and I am glad that I did. Chad Fowler gave an address on what it means to remain passionate as a developer over the life of your career. I think his idea that providing structure to your life definitely allows you to achieve amazing things. His real-life examples were poignant and well received. I’ll be checking out his book soon. The other talk that I found interesting was Jeremy Hinegardner’s talk which basically discussed the numerous non-relational persistence methods available. I thought his method for showing examples of the different methods was great. For each one he had a simple succinct example that showed the benefits for the given persistence framework. He allowed the audience to choose from the frameworks he discussed in his talk. Jeremy was an engaging speaker, and I would not hesitate to sit in on one of his talks in the future.
After a bit of DD-provided BeauJos, I headed over to the UnCon. They too were having pizza provided by Google. Google Boulder was a great sized venue for the 40 people that attended. It was exciting to see so many new faces in attendance. It seemed to me that the “regulars” were doing a lot of demoing, while the new folks watched on, but there was also a lot of discussion that happened. I showed how to use repoze.profile and runsnakerun to
analyze the results. Zooko immediately installed runsnakerun and tried it on his app. It is always nice to have immediate gratification for having taught someone something, even more so when the person voluntarily tries what you think is “so cool.” I got to show off some of the work I am doing for www.getmvp.com, since much of it is prototypical of the Extension Solution that I hope to provide with a combination of Pylons and TG. Also on display was TW2. It was great to show how simply one could express all MVC elements of a widget in one complete package.
Sunday I ran the first TurboGears WorkShop. If you follow my blog, you may have read a few posts about how I think we can improve sprinting, but I’ve come to the realization that our less-than-stellar sprint performance is really due to a need for improvement in the organization at large. I have decided to add a WorkShop Series to our tireless effort for improvement of TurboGears, both from a technical aspect, and one of the community. I was up late on Wednesday creating a basic tutorial-type plan for Sunday, and I finished up with about 80 pages of documentation to provide workshop goers, basically by selecting items from the TurboGears documentation. My goal for the sprint was to provide sprinters with a working example of TG at the end of the day, with a little bit of work accomplished customizing the Admin. I asked sprinters to bring their own databases, to utilize sqlautocode as an example database for their new application, and while no one provided the class with one, we were still able to succeed with one that I provided as a backup. 5/6 people succeeded in this, and while there were some rough edges, I think I have an idea that is workable for a 3-6 hour WorkShop that will succeed with a little bit of polish.
I am still formulating the ideas for TurboGears workshops. I have started to contact folks I know throughout the country, in order to provide venues for these workshops. So far I have Boston, Dallas, San Fancisco, Atlanta, and Boulder (Denver) lined up. I think with little effort, I could also add Ann Arbor, and probably Washington D.C. The idea behind a workshop is that you arrive with a varying amount of knowledge in TG, and you leave with a greater knowledge than you arrived with. You are encouraged to bring an existing project to hack upon, or to create a new one that we can play with. I will provide a rough outline of what we might do in the tutorial, but if the group decides to go off in a different direction, that’s okay too. If you are interested in participating in one of these WorkShops as a mentor, or providing venue space, accommodations, etc. I would love to hear from you. Right now I am in the organization phase, expect a blog post announcing the official plan in the near future.
Thanks! Without the efforts of a number of individuals this weekend would have been much less successful than it actually was. I want to thank Ben Scofield for inviting me to talk at developer day, and for shuffling the schedule so I could participate in both conferences. Greg Holling put in a great effort to organize the Uncon, and Google provided an awesome venue for us to use. Three volunteers from Google Boulder provided their time, and even gave a tour of the facility to conference goers. They weren’t even Python developers… Jim Baker and Matt Boersma both showed up to provide access to Bivio so that we could have our first-ever TG WorkShop. Lastly, I’d like to thank Bruce Eckel for making the trip down from the mountains to provide his unique perspective.
I’ve been thinking out how we can come up with new methods to make our sprinting time more productive. In the first two segments, I went over what our current thinking about how a sprint should run and what is expected of organizers and sprinters alike. We see that sprinting is somehow broken, because people lack motivation to sprint,
except the folks that rise to the level of elders.
All is lost with sprinting however. I think that there are a few things that
we can do to make sprinting more productive. The challenge is that you can’t just make rules and expect sprinters to respond. You can
’t say, “don’t show up without knowing what you are doing,” or we will lose valuable input from the community, since only elders will show up at that point. So, the new rules are for organizers, and the elders, not the would-be sprinters.
Organizers need to start offering free tutorials for folks interested in the projects. This accomplishes two things. First, you give training to the people that are interested in your project without alienating them. It would be easy to say “New Rule! You must have done the 20-minute-wiki tutorial to participate in the sprint.” But this tactic does nothing to help the feeling that people have when they call something elitist. While you might think it’s not elitist to have accomplished the 20-minute-wiki, someone else might struggle for hours with that task, especially if the documentation is not up to snuff. These contributors still offer valuable insight, and you want them contributing to your project.
The second reason free tutorials will help your project is that it gives you an opportunity to increase the popularity of your project. The more people that are interested in your way of doing things, the more potential sprinters you have. At the end of the tutorial, you can collect emails or instant message handles, even phone numbers if that is what it takes to grow a list of perspective sprinters. If you are willing to be generous with your time, maybe 1 out of 10 tutorial goers will be willing to return the favor. The tutorial would also allow you to open up a method for communication. Consider setting up an IRC (Internet Relay Chat) channel for your sprint, or using your project’s IRC channel to disseminate information about the sprint. This will show folks on IRC that you are not only doing a a tutorial (maybe you will get some online participation) but it will show tutorial goers that the channel exists for further assistance.
The free tutorial is a great way to provide a service that costs nothing more than time for the organizer. However, I don’t think this is the limit of what we can provide sprinters for their time. What we need to do is provide some sort of incentive other than the good of human kind to sprinters. The first thing is probably the easiest. Start holding sprints on a friday, or any weekday for that matter. This seems counterintuitive, right? The fact is, most people don’t want to take a weekend day off because they are busy with other weekend stuff. We all have families, clubs, interests outside of OSS software that we need to tend to. Also, this provides a monetary benefit to the project without actually costing the project anything. Many companies which use OSS software, and claim to support it will also be willing to let their employee take a day, or a 1/2 day to participate in a sprint. The way you sell this idea is
to have the sprinters describe the hands-on and in-depth training they will be receiving in the care of the sprint. This is no lie, the amount you can learn in an average sprinting day far exceeds the amount you receive on a regular basis.
Hold sprints in a unique location. Lots of people like to ski. For this reason zope/plone’s snow sprint is very popular. I think the reason this sprint is made possible is that people need to take a break from the every day, and getting to a new an exciting place has merit, both from a coding perspective, and a mental aptitude one. It so happens that I live in Colorado, which is one of the premier places in the US to ski. If anyone is interested in organizing a sprint nearby, I urge them to speak up. Also, I would be willing to provide a free tutorial on a weekday, so that hourly employees may be able to justify the cost of a trip to Colorado as an offset to the cost of free training.
It seems to me that the scope of a sprint is essential to it’s success. If the sprint is just to code something, it is much less likely to succeed than if you are to sprint on something in particular. Having everyone making a concerted effort on one topic makes it easier for organizers to coordinate folks, because organization can focus on one thing, and therefore tasks can be created ahead of time instead of doing so when everyone shows up.
Lastly, I think we need to reach out to the community of users, and find out if users of your project can support the OSS efforts of the tools they use. I think that the next logical step is to provide sponsorship for sprints themselves. Perhaps the sprint sponsor can provide a place to stay, or airfare to bring some of the sprinters together. Even providing a venue for the sprint, or beer and pizza is something, but it is hard to expect people to show up and spend their time and also their own money to be co-located with a bunch of other sprinters.
This is part two of a four part series on sprinting: The next [controversial] post is called Sprint Organization: But can we do more ? This will talk about how we might convince third parties to participate in the concept of sprinting by asking them to donate monetarily.
So, as I stated in a previous entry, I’ve been using SQLAlchemy for more than three years now. If you know anything about me, you’d find it amazing that I have contributed little more than a patch here or there. Why is that? I think that’s because every time I try to find something that I need SQLAlchemy to do, it already does it. I have spent so little time trying to make SQLAlchemy do what I want it to do, and so _much_ time getting work done with it.
Here is a good example. One o
f my clients is a
company developing sports management software by the name of MVP. Although I work on their next-gen stuff, I was called on by them to promote the students on the older system to the next grade over in the summer time. Their database system had well over 40 tables, requiring no less then 10 of them to have modification. I fired up sa, reflected the changes, wrote the changes in python, with simple loops around what records I needed to change, an it was done. In one hour’s time I had a happy client, and a school system with a functioning system. Two things about this are amazing. 1. At the time, I had practically zilch in the Postgres experience department. 2. I only needed to learn the schema of the tables I was modifying, and I could do this with introspection. The fact that I was able to do this task in less than an hour was only made possible by my knowledge of SQLAlchemy’s table-based architecture. I did not need to know the nuances of Postgres’ SQL language (I was more familiar with MySQL at the time), or a in-depth knowledge of the database schema. I was able to pick and prod until the job was done, and it was painless.
I really like the fact that SQLAlchemy’s approach to making an ORM is layered. I can drop to whatever layer I need to to meet the requirements of my project. SQL, table objects, and mapped objects all have their place in the grand scheme of things, and I have used them all to varying degrees. What SQLAlchemy achieves with this layering is the ability to adapt to existing projects, schemas, etc, and make considerably useful software, in a short amount of time. By figuring out the nuances of different SQL dialects, it frees me up to focus on the task at hand, and provide products to my clients that work in a broad range of situations.
But this post is supposed to be about TurboGears, right? For me, SQLAlchemy is more than a tool I use for TurboGears projects, or even web applications, it’s something I can use any time I have to access a relational database. It is the ultimate base for writing tools that help me get my job done. That job might be providing a system to allow schools to schedule matches against each other, or enabling scientists to access their data directly using objects at a python prompt, instead of assembling arcane sql strings to gather data. SQLAlchemy is such a good basis in fact, that it makes building tools to help do my job even easier.
I have had the opportunity to contribute to sqlalchemy-migrate. If you don’t know anything about the project, consider this: You have a production database you cannot break. You have 5 minutes downtime to modify the schema, update records, etc. You need to be able to back out the changes and bring the system back up if everything breaks. Migrate lets you do all of this, and provides a versioning system to ensure that such a process moves smoothly. I have used migrate with postgres, found some rough edges and fixed them. SA’s table mapping makes this possible, migrate just adds a layer to make versioning and some table creation processes easier. I only hope that someday some of the migrate code makes it’s way back into the SA codebase.
I do lots of testing. I made numerous schema changes today to one of my databases at www.nrel.gov in fact. I test the database schema for
matching against my definitions with some yet-to-be-released software. There are about 3000 tests. With tables numbering in the fifty-semod, I needed something to make data entry easier for my tests. I wrote bootalchemy to do this. You pass it some YAML, and the models module, and it performs all the entries for you. It does a bit of introspection to determine dates, and it has reference pointing so you can inter-connect your objects within your yaml (using & and * like my old friend C). This has vastly decreased the amount of time it takes me to create new test data for new tests. Again, this is possible only with the framework that SA provides me.
Lately I have been interested in providing a broader base of scientists at NREL access to their data using python as a medium. Scientists (especially physicists) are really good at conceptualizing data. They use crazy tools like Matlab, and R and all sorts of proprietary tools to manipulate their data. They aren’t afraid of a command prompt. My idea is to give them something like Sage, but with direct access to their data as mapped objects. I also want to be able to show up at a scientist’s desk with laptop in tow, connect to one of their existing databases, and spit out a admin-style web interface based on TG in a few minutes. These notions have driven me to contribute sqlautocode. At this point sqlautocode will spew out a page (or 7) of python code that provides you with Declarative Objects and an interactive prompt. sqlautocde works as a library, so you can use saautocode’s output to directly in memory without generating any code at all. All this is possible with SA, and I don’t know of anything else that can do all of this.
I have focused on the technical here, but beyone that is a great team of individuals like Mike Bayer and Jason Kirtland who put in long hours and answer questions promptly on the mailing list. I often wonder how these guys get any sleep. The thing that excites me most about SA is that it will soon release version 0.6, which to me means that these guys have 4 more versions of increased functionality before they consider it “done.” So, as you can see, there is more to SA than just the ORM it provides. It’s framework gives you freedom to expand your horizons and get your job done, by focusing it’s task on the challenges that relational databases all have, so you don’t have to. This is what makes SA a killer feature of TG.
The third segment in this series is: TG’s Killer Feature: The Admin (Yes, We do, and it rocks)
We get a lot of refugees who come to TG from other frameworks where they got themselves to a place they could not get out of. I have worked with some of these frameworks in the past. Things are awesome in the beginning. You work on some less complex stuff, maybe change a template around, or the theme for a site. Then you have some technical detail you need changed and BAM! You just hit the wall. Now you are forced to dig, or suck it up and go on IRC and ask noob question. Many times I find myself getting shut down, told to RTFM, or whatever.
With TG I never really felt the wall. TW was a bit of a hump to get over, but seriously, things are so un-coupled in TG that using a technology you are already familiar with, or swapping out the standard stack is not something totally unheard of. I for one do not like working with Genshi. I’ll do it, and I support it for major OSS work I do, but really I prefer Mako. Mako is fast, works in a non-xml way (which makes it great for writing form-emails for instance). What this means is that TG has good support for Mako in the “standardized” parts like the admin.
The thing is, we really did not have to add much to TG to allow it to work with Mako. I think one of the ingenious things that TG supports is dotted template lookup. What this does is allow you to pull data from any package, because the lookup occurs using pkg_resources. Beautiful, now we have the ability to move templates into their own succinct packages. Also, we support non-dotted template lookup for template languages like Jinja, and adding support for dotted lookup wouldn’t be too hard to do in the future.
The new TGAdmin interface is another example where hitting the wall is just not something that happens. TGAdmin is built on new technologies for TG2.0. Namely RestController, Sprox, and lookup. It creates a custom controller for each of your model classes, and therefore you have a good place to start from when you get going with your application. This is great for demoing. With SQLAutocode, Sprox, and TGAdmin you can literally hook into your client’s database (MySQL, Postgres, sqlite or MSSQL) and generate web forms where you can have an infinitely scrolling tableview, edit, and create forms. From there you have the ability to customize further, by hiding table/form fields, changing the look and feel of any component in the chain. This is made possible by Sprox’s configuration interface. You can also modify the controller code for each model by adding controller methods to your default controller in the admin’s config object. All of this customization is outlined in a tutorial.
The great thing with the new TGAdmin is that since it is based on Sprox, you can re-use the knowledge of sprox externally to the admin, and also bring any existing knowledge you may have about ToscaWidgets to the table. You can even use sprox outside of TurboGears for any other python web-based applications that you have that also use SQLAlchemy (read: Pylons).
To get back to the TurboGears discussion, a lot of folks don’t want everything that TG brings to the table. Some folks need different auth/auth models, have no use for a widget library, or even a relational database connection. TG can serve you too, and it’s still fast. Recently SourceForge moved over to TG for their main website. This requires a connection to MongoDB on the back end (read: no SQLAlchemy), zero ToscaWidgets, and a different authentication method. According to Mark Ramm, they had started with a different framework which lends itself to the Jinja2 templating engine. As far as I know, Mark was able to meet all of these goals, and eliminate 9/10ths of the server load they had with their previous system, written in something non-python. This just goes to show how flexible TG was to be able to meet all of these needs, and still provide a technically sufficient solution. Maybe he will comment more about this in the future.
Now, there are those folks out there who have decided to role their own. And WSGI definitely supports, if not encourages this behavior. But I just have to ask: Who’s agenda are you really fulfilling? Even if people like your code and you have a small following, are you helping to further the benefits of your projects, or your career in general? Are you helping your customer in the long run if you leave the project, or leaving them with a dead-end piece of code? Will they be able to find someone to replace you, should you decide to leave?
TG has an active community of folks who are willing and able to help get your contributions into the main code branch. We have embraced mercurial, and use it’s abilities to offer a lessened barrier for those who want to contribute. So, please, before you go make your own framework, see if you can help us make TG better, and your reward is that you now have a community of folks that will help maintain your work, even if you decide not to.
Basically what I am saying here is that TG has an even learning curve. Sure, as you get more involved, the problems will get harder, but you wont end up having to re-write half of the framework just to get it to do what you want. And, if you do find something that needs work to meet your needs, you have options to participate in the development of TG.
In 2008 TurboGears ran a sprint series to flesh out the 2.0 release. We successfully released in Spring of 2009, thanks to the hard work and dedication of a number of folks who saw the process through. This was a great opportunity for folks who wanted to be actively involved with a web framework to jump in. It is very likely in the coming months that TG 2.1 will see the same sort of community out-reach as we prepare to move from a development cycle, to a release one. So, look forward to that, find out how you can contribute, and by all means, give us feedback as to what you really want from a Best of Breed framework.
I think a lot of people wonder what’s happened to TurboGears. Where is TG going? Where has it gone? In a recent mailing list post, we were blasted for our documentation, or lack there-of. People seem sort of frustrated that they have a great tool in TG2.0, but have to spend so much time isolating their own technical problems that they fail to see that there is considerable documentation in most areas, but that the docs have a few sore spots here and there.
2008 was all about making TG2 _work_. We’re past that now. Most things pretty much work, some things work really well. Other things need some attention. Now that we’ve got the hard part of actually designing a functioning framework, we can focus on documentation, and using that valuable framework we have written to push the envelope of what TG can do.
One of the “things” we need provide to the user community is better documentation. In the past few weeks I have seen more drive in our community to improve the docs than ever before. Michael Pedersen has taken over responsibility for our documentation. I cannot thank him enough for his work, both in reviewing, reorganizing, adding to, and fixing errors in our existing documentation. His kind of no-sacrifices attitude towards the docs means that we won’t just have “something” up there, we will have what it takes for developers to create web applications using TurboGears.
ToscaWidgets is a sore spot for a lot of folks. I feel your pain. Lot’s of folks say you don’t really need TW to do what it does because you are just creating HTML forms, what is so hard about that. Well, I’ll tell you that I could not have written Sprox without it’s flexibility. Here’s the good news: TW has been re-written from the ground up by Paul Johnston in the past few months. I’ve been helping in this process, providing the tests that will make it more stable than the previous version, and making sure the codebase is not so complex a feeble mind like my own cannot comprehend it. I spent some time benchmarking it, and making sure it’s as fast as it can be. TW2 is 2x as fast as TW. It approaches the speed of simpler frameworks that _only_ produce html (they don’t do resource injection, parameter cascading, etc.)
On other fronts, Jorge Vargas and I have been working on integrating MongoDB with Sprox. This will become the “killer app” for sprox 0.7. For me, this represents proof of concept for Sprox. We have successfully integrated the basic workings of MongoDB into Sprox, which means I generalized in the right places enough for this to work. The result is a TG Admin that will work for MongoDB or for SQLAlchemy equally.
So yeah, there’s still a lot of activity on the TG front, and if you pop into IRC you can feel free to chat up at least one of the TG dev team at almost any hour. Also, we are having a DocSprint Sept. 25-27 (with a main emphasis on Sept. 26), in Boulder, CO and worldwide remotely. We will be addressing the over 100 todo items that Michael has so graciously gathered for us.
This is the first part in a 3 part serious on TurboGears. The next part is entitled: “TG’s Job is hard. Here’s why.” which will discuss various philosophical challenges with running a project like TurboGears.
