Our friends at Phizzpop are throwing a pretty cool little contest for web design firms- pitch a redesign for Boys and Girls Clubs of America, and the best idea wins $50,000. They say it’s a chance to give the country’s oldest nonprofit a web 2.0 upgrade. We say it’s a chance to do something good and win a trip to vegas to boot! Deadline is Feb 19. See you there.
January 19th, 2010
I’ve already professed my love of breaking out of the browser a few months back. They’re awesome, and fun, and not terribly hard or expensive to build- but they do present an interesting opportunity/problem. What should a good “internet app” look like?
One approach is to just go nuts and make it looks however we like- that’s what we did first time out of the gate, with rssTunes. I’m pretty happy with it, it’s cute and integrates nicely with the website and hopefully it brings a little bit of joy to our users whenever they fire it up to rock out to music curated by their favorite curators (/plug). But it might be a bit much for a “real” app you’re supposed to interact with in a cubical for 8 hours a day. Or maybe you’re tinkering on the ultimate time wasting socially enabled applet ever, and you’d like it to be somewhat discreet among your Outlook and Spreadsheets and TPS Reports instead of screaming “HEY LOOK AT ME DOING ALL THIS WACKY STUFF ON THE TUBES”.
So the dilemma- making your app look natural inside a modern desktop OS, which for the sake of discussion we’ll limit to Windows 7 and Snow Leopard. While they each have their own unique user experience (and quirks), at this stage in the game, they both present a similar level of polish and graphical snazziness. And we’ve also seen cases on both platforms where indie developers have moved away from system generated resources without going completely off the reservation and making an app/experience that just feels “right” on it’s respective platform. Our goal in our next RIA? To craft one core look that is modern, clean, and most importantly- easily able to fit in like a first class native app on either platform.
Without giving away too much, our initial pass illustrates it might be possible. The core artwork is just about the same in each implementation, with the coloring/tinting handled programatically. Here, take a peek:
Our mystery app, which apparently does little more than showcase tweets of advertising luminaries at this point, appears to be comfortable swinging both ways. I will let Jack tackle the black magic of platform detection, but- assuming he gets it working- the user will be oblivious to this nifty bit of UI ambidexterity and the app will just show up looking “right”. Cool.
December 23rd, 2009
This is exiting:
MonoDevelop’s cross-platform compatibility got a boost in this release. A native Win32 debugging backend is available and MonoDevelop is now fully supported on Mac OS X. Support for Python development with code completion, folding, and syntax checking is also included in this release. The developers have started adding experimental support for Moonlight development, but caution that the Moonlight add-in is still in the alpha stage of development.
Moonlight, the Linux version of Silverlight, has always lagged behind Microsoft’s official release by at least a version. But the cycles are getting faster. The lastest release includes a few SL3 features, and the lead developer’s brain is already excited about what SL4 will bring to table in terms of cross-platform applications.
And lest anyone thing this is all a mirage just waiting for the inevitable patent lawsuit, Microsoft released a new agreement guaranteeing they’ll never sue Moonlight end users.
I’ve just dipped my toe in MonoDevelop, and while it’s not nearly as great a tool at SL development as Visual Studio/Expression are today, you can see they’re trying.
Exciting times people!
If you’ve already got CS4 or MS Office, and you’re thinking about grabbing Expression, either for yourself, or maybe as a lovely Christmas gift for someone you know, MS is running a promotion where you get 30% off. So, happy early non-demonational holiday.
December 7th, 2009
Now that we’ve been doing this three months, I thought I’d summarize some of the bits about developing in Silverlight that I’ve come to love, even miss, when I’m working in other environments.
5. Out-of-browser applications
I’m sorry, but comparing Adobe’s AIR to where Microsoft is headed with Silverlight, and it’s no comparison.
One environment requires not only writing two versions of our rich media application – one for the web and another for the desktop – but requires your users to download and install a separate runtime environment just to run the damn thing.
Yes, Silverlight’s out-of-browser is still really immature. I’ve been following the Silverlight 4 beta, and it looks like it’s getting slightly better. Not “you could write a word processor in it” awesome, but it’s gonna get there.
4. MediaElement
Two of our three public projects have made use of Silverlight’s MediaElement. Our video player uses it, and rssTunes uses it to play MP3s.
I’ve “written” numerous video players in Flash, and one or two MP3 players, and the difference is stark. In Flash, skinning the default video player is an exercise in absolute hell.
In Silverlight, you just get a control that handles actually displaying the video or playing the audio, and you build the controls around it. The control exposes every event and state you’d need.
3. Control Templates
I mentioned this in yesterday’s post, but it bears repeating. The fact you can override the entire visual tree for any control, without having to subclass it in code, and wire up the events all over again, is a just a huge time-saver.
2. Visual Studio
As much as it pains me to say, Visual Studio is arguably the best IDE I’ve ever used – so long as I’m working with Microsoft technologies.
The difference between it and both the Flash IDE – a ludicrous hideous interface ghetto that no one would subject themselves to if they had a choice – and even my beloved TextMate or Xcode is ridiculous.
1. .NET libraries
More than even the IDE, the real advantage of development in Silverlight is all the wonderful things Microsoft has packed into the .NET libraries. Things like JSON parsing, a tedious chore of external libraries in other environments, is built in, and works fantastic. WebClient is one of the cleanest asynchronous HTTP APIs I’ve ever encountered, and beats the hell out of cURL.
It’s thought through, well-documented and extensive. There are a few holes I’d like covered, mostly related to image manipulation and conversion, but otherwise, it’s a dream.
December 4th, 2009
It’s been about two week since I launched our first Django-based web site hosted on our IIS box, and I’ve gotten a few AIMs, and emails from folks with an assorted array of questions. Maybe the answers will help others.
Why would you host on a Windows box instead of Linux?
We host numerous sites for our clients, and write sites using whatever technology fits the bill. Truth be told, for all of the benefits of a normal LAMP stack, if I want to work with the full assortment of web languages, including ASP.NET, a Windows box makes sense. They’re more expensive, yes, but as far as I’ve seen, the performance is on par with, or better than, my normal Linux setups.
So for Mess, it makes sense.
Did you have to hack the Django core at all to get it working right?
No. Luckily, the guys who wrote Django are fantastically smart, and wrote the core in an OS agnostic way.
I am not that smart, and I did have to make numerous modifications to my own Django-apps to get them running. The biggest issue was file paths. Instead of a using a simple string for paths, I now wrap all file operations with os.path.normalize. I continue to write using Linux style backslashes, since it’s habit at this point, but the paths work on my Mac when I’m developing locally, and on the IIS box when I deploy.
I also had to rip out all of my print statements. PyISAPie echoes any print out to the browser, so the first few tries I had lots of broken HTML, extra returns and debugging messages. I switched everything over to use the built-in logging module, and it worked well enough.
What’s performance like?
I’d say it’s “fast enough”.
I don’t have comparison benchmarks to give, as I don’t have a Linux box anywhere that’s comparable to the Windows box we’re running these sites on, but I can tell you that load testing has shown that IIS + Django performs just fine.
I do my load testing using siege, and the box consistently rated as being capable of handling 150 requests per second without breaking a sweat. The closest Linux box I have to test it against has half the RAM, and a much slower CPU, and it can generally deal with about 45 requests per second without too much fuss. But that is so not an apples vs. apples comparison.
Would the setup you mentioned work with IIS7 and/or Windows Server 2008?
I don’t see why not. I’ve only heard of one confirmed installation on that setup, so your milage may vary.
What about WSGI?
I tried it and could not manage to get it working. At all. It’d crash nearly ever other request, or just fail to start. Occasionally, it’d run great for an hour and then take down the IIS process.
In theory, it’d be absolutely awesome if there was a solid port of mod_wsgi for IIS, so we could deploy a single version of our Django sites to both our internal Linux staging server, and our production Windows machine.
In theory, communism works. In theory.
December 3rd, 2009
Generally speaking, “rebuilding” an application is a relatively bad idea.
The first build of rssTunes had already taken me about two weeks longer than we’d estimated, and I was relatively happy with how everything had turned out. If you hadn’t looked at my code, you’d never know there were any issues with it.
But there were.
Being new to Silverlight development, I’d been approaching interface development that same way I’d approached development in Flash. After Rob and his team had completed the interface mockups, I’d break the interface down into individual controls – play button, volume slider, pause button, etc. – and import each control into Blend. The controls would be made of nothing more than a whole mess of Paths, which I’d then rebuild using things like Rectangles, Borders and a few complex Paths where necessary. I’d then start plugging away in Visual Studio, adding event handlers and timers left and right to make those basic shapes behave like whatever control they were supposed to resemble.
Consider the duration bar in rssTunes.
Beneath the artist and track name in the player, there’s a progress bar that updates to show you how much of the current track you’ve played. It’s a fantastically basic control, but I felt my first implementation was barely above amateur grade.
The duration bar was built using three Rectangles, one layered atop the other. The bottom most was stretched across the entire width of the player, and then I had a second one that started off with a width of 0. Every second, I’d check to see how much of the track the user had played – since he could of paused the track – and manually calculate how wide the second rectangle needed to grow to reflect that.
I’d written over 200 lines of code to create nothing more complicated than a progress bar! Worse, it didn’t even support every state we really needed in the application. When a track was buffering for instance, the progress bar should really have switched to an indeterminate state, to reflect that I didn’t know how long was left in the track. But doing that would have required another 100 lines or so, and I was already behind schedule.
Now, there’s nothing wrong with doing things that way. It’s how you have to build custom looking controls in just about every application environment under the sun. Basic shapes, lots of code. It’s just how its done.
But it was a massive waste of time in Silverlight.
Part of my attraction to Silverlight and is how it handles interface controls. Out of the box, Silverlight includes fully-wired interface elements of just about every kind; buttons, progress bars, tab controls, tree views – you name it. This lets you get a working interface up and going quickly.
But Silverlight was also built with the understanding that you’d probably want to customize the way those controls looked. Instead of having to jump through the usual hoops – creating a subclass of the control programmatically and overriding all of the drawing routines – you can customize the look of the control without writing a single line of behavioral code.
Silverlight uses a concept called “templates” to separate behavior from appearance. Every control has a template; a collection of shapes and other controls that make it up and form its “visual tree”. In the case of a progress bar, there’s a set of rectangles just like I’d built on my own. But the template also includes things like states and transitions.
Behind the scenes, Microsoft’s already written all the behavioral code to make the progress bar grow, disable itself and to display an indeterminate state. All we have to do is override the control template, and make whatever changes to the appearance we want. We don’t have to worry about the wiring.
Blend makes this really easy.
In Blend, you can edit these templates visually. You just click on the control you want to edit and select “Edit Template” from the menu bar. You’ll get a list of all the states that control has, and you can go through each state and edit it to your hearts content.
When we started the rebuild, I decided to do this for all of our controls. Instead of building up every single aspect of the UI from scratch, and then wiring up each control with a bunch of MouseDown, MouseUp and Timer events, I just created a handful of custom control templates – one for each type of control we needed.
The resulting project, which is up on CodePlex for your review, is massively simpler both in the XAML and in the C# code that drives it. The code no longer reads as a bunch of shape manipulations. Reading the code, you can tell I’m working with specific types of controls, and there’s way less code devoted to interface junk.
Best of all, I get tons of behavior for free. The buttons in the first version of rssTunes were really just static images. You clicked on them, but very few behaved as you’d expect. There were no roll-over states on buttons, or click states. Now, every single interface control has the full range of states.
I didn’t have to write a single line of code to do it.
December 2nd, 2009
Since launching rsstunes, Jack’s rolled out a bunch of little code fixes and upgrades behind the scenes. Which in and of itself probably isn’t that exciting, thats what developers are supposed to do- develop. What is cool is that a lot of work was the direct result of feedback- sometimes suggestions, sometimes bug alerts- that we’ve received over Twitter. (For the last round of tweakage, I’m looking at you @creamteam and @pmablog).
It’s nice having folks that aren’t staring at your project all day give feedback- especially now that these RIA tools are letting creative types build applications instead of websites and widgets. On a lot of typical websites, you might have a client contact to please, but after that you’re generally home free. The desktop is a different beast. People really use applications, and we’re going to have to adjust a little and be responsive if we expect that cool little doodad to sit down in the dock all day instead of get played with for 30 seconds online.
Not trying to be a downer though. It’s sweet to be able to make an app without a hardcore dev team. And, if you’re open to talking to your users somewhere convenient (ie: Twitter) getting good feedback isn’t just easy, but it’s also kind of fun. People like having their needs addressed, and if you respond to them we’ve found more often than not they will bend over backwards to help you get to the bottom of the issue at hand. And- bonus- they might even tweet to their friends about your app since you’re such a responsive guy/gal.
RIAs open the door to lots of awesome new possibilities. Just be mindful that they may also carry some responsibilities as well, and commit to being communicative with your users. Also, if your audience happens to be mp3 bloggers, I can pretty much guarantee you will hear something new you like to boot.
November 11th, 2009
Part of the terms of this project were that we deploy and use a Windows server running IIS for both the blog, and for any other subsite, such as rsstunes.com.
As I’ve mentioned in previous posts, I was pleasantly surprised to see just how easy the Microsoft Web Installer made getting PHP running on Windows. If you’ve got to do it, there’s no better way.
A vast majority of our internally development over the last year has been in PHP. It’s an agile, relatively mature language, and it runs just about anywhere a client could ask it to.
But as we’ve matured as a development team, I’ve been pushing us increasingly towards using Python, and an excellent web framework called Django.
Django, and Python, are most assuredly not supported by the Web Installer, and while I knew I might be shooting myself in the foot, I decided that, for the second version of the rsstunes.com site, we’d use Django, and I’d sort out how to get it running on IIS.
Since the vast majority of Django developers are running a standard Linux stack, there are few, if any good resources out there on getting Django running. There are a few hints, and assorted messages strewn about mailing lists, but nothing authoritative.
After about two weeks of configuration headaches, and crashes, I’ve managed to get a stable, production ready installation of Django running.
Here’s how.
Python.
Before you get started, you need to get a copy of Python running on your Windows server. The easiest way is to download and install the Windows Python 2.6.4 installer from Python.org.
I installed mine at the root of the C: drive under a folder called “python”.
MySQL & Python MySQLdb
For our projects, we develop using MySQL as our database server. If you’re using Postgres, you’re on your own getting everything running.
First, You’ll need to download and install MySQL. There are MSI packages available from MySQL.com. I recommend using MySQL 5.1.
I’d also recommend snagging the MySQL GUI tools. It makes administering the server on Windows infinitely easier.
The final hurdle to a working Django base is to install the Python bindings for MySQL, which, at least on my Snow Leopard installation, can be a real pain. Lucky for us, CodeGood maintains a binary installer for the MySQLDb Python module for Windows. Download and install it.
Optionally, you may want to install the Python Imaging Module, or PIL. Trust me, doing it now will save you some time.
Testing Django
Download the most recent release of Django and install it into C:\python\Lib\site-packages.
Follow the Django Getting Started Tutorial and get a very basic Django project running, just to verify your Python installation is in working order. Chances are, it will be.
IIS & Python
As best I can tell, the standard operating procedure for running Django on a Windows Server is to install Apache and run it under mod_python or mod_wsgi. This seemed fantastically silly to me.
First, Apache, while it runs under Windows just fine, always feels like a kludge when running under Windows. All of the UNIX conventions just stick out like a sore thumb. Seeing that IIS is so stable and awesome at running PHP, why wouldn’t it work to run Django?
The best option seems to be PyISAPIe, an ISAPI plugin for IIS that allows Python scripts to serve web pages. I tried a few other options, such as isapi_wsgi, and just couldn’t keep the server running for longer than one or two requests without a crash.
Download and install 1.1.0-rc4 of PyISAPI and install it. I’d recommend installing it at the root of the C: drive, just like we did for Python.
Your Site Structure
Each Django site will essentially need it’s own copy of the pyisapie.dll file, and it’s own configuration files.
The directory structure I ended up going with broke down to two folders.
Under my inetpub directory, I created a directory called “sites”, which will store each of my Django-powered sites. Each project has it’s own directory under that, and within each of those directories I have a folder for pyisapie and another for my Django project.
In the case of rsstunes.com the structure looks like this:
The “log” and “public” folders aren’t strictly necessary.
Inside of pyisapie, I have a copy of the DLL file, and the configuration files. Here’s a ZIP archive of pyisapie folder, which you can use to get started.
Next, place your Django project in the python subdirectory.
Configure IIS
We need to register PyISAPIe as being a valid server extension in IIS, and it needs to be setup very specifically if you want to run multiple Django-powered websites.
First, we’ll need to register our site-specific copy of the pyisapie.dll file. Open your IIS Manager, and click on “Web Service Extensions”. Next, click on “Add a new service extension”. Give it a name you’ll recognize (I went with “rsstunes python”), and then click “Add”. Find your site folder, and under pyisapie, click to select the pyisapie.dll file.
Click the checkbox next to “Set extension to Allowed”.
Configure an Application Pool
Due to how PyISAPIe works, you’ll want a separate Application Pool for each of your Django-powered sites. Performance wise, this isn’t great if you’re planning on running dozens of Django sites on one server, but it works great for a handful in my testing.
In your IIS Manager, right-click on Application Pools, and create a new application pool. Again, name it something that will make sense to you.
In terms of settings, I’m still tweaking. For load testing, I use a tool called siege, and check to make sure the server can handle a minimum of 100 requests per second. To achieve this, I set the application pool to recycle workers every 60 minutes, and after 250 requests. You can play with the settings and see what works for you.
Add the Site
Add a site as you would normally under IIS. I set my home directory to that blank “public” directory you saw earlier. It doesn’t actually matter since we’re going to point all requests at our PyISAPIe file.
Under Home Directory, give your application a name, and click “Configuration”. Under Wildcard application maps, click Insert, and browse to your site-specific PyISAPIe.dll file. Make sure “Check that file exists” is unchecked.
Since serving static files with Python is pointless, I’d also go ahead and add a few Virtual Directories for your static files (generally stored in your Django project’s “static” directory), and, if you’re using the Django admin, one for “media”, pointed at C:\python\Lib\site-packages\django\contrib\admin\media.
Lastly, make sure you set the site’s application pool to the one you created earlier.
Edit Isapi.py
The file Isapi.py under “pyisapie/Http” is the actual adapter file PyISAPIe looks for and uses to serve up a request.
You’ll want to do two things.
First, append the full path to your Django project to the system PYTHON_PATH using sys.append, as I’ve done in the example.
Last, you’ll want to set os.environ['DJANGO_SETTINGS_MODULE'] to your projects settings package.
Start it up
Once you’ve done all that, stop the Application Pool you created and the site. Start the application pool, and then the site. And yes, the order matters.
Visit your site’s URL in a web browser, and you should see your site up and running.
Windows 7 launched last week. (Unofficially, it’s been working great for us here even though it’s technically unsupported by both Bootcamp and VMware Fusion 2.) We were super stoked to see that the shipping retail release came stock with a shiny desktop designed by Chuck Anderson/No Pattern. Pretty slick work, and kudos to Chuck– that’s a nice piece to have in the book!
