Microsoft Web Dev Summit 2009 – Ben Ramsey

For the past three years, Microsoft has hosted the Microsoft Web Development Technology Summit, inviting a small group of community leaders, project developers, and prominent members of the PHP community, primarily for the purpose of eliciting feedback on how to better support PHP on Windows. I’m privileged and honored to be invited back for a third year to the fourth annual edition of this summit.

This is the first time I’ve ever blogged about the event, though I’ve taken “live” notes during the 2007 and 2008 summits. I’ll be taking notes again this year, if you’d like to follow along, but I’ll also be devoting several blog posts this week to the event because I think it’s important.

As I said, this is the Microsoft Web Development Technology Summit, but perhaps it’s not very aptly named, since it could best be termed as the Microsoft PHP Summit. Then again, one could argue that PHP really is the server-side technology of the Web, so calling this a web development summit is appropriate, and I think Microsoft understands that. This is the first reason I think this summit is important: Microsoft recognizes the importance of PHP to web development.

The second reason it’s important follows closely on the heels of the first. Because PHP is important, Microsoft wants PHP to work as best as it possibly can in a Windows Server environment, eliminating all performance arguments in comparisons between Windows/IIS and Linux/Apache. This reduces the platform choice argument to one of subjective preference with no basis in objective analysis. This is good for Microsoft because many PHP developers continue to use Windows as their local development platform, while deploying to *NIX systems. All performance arguments out of the way, if developers can deploy to the same platform they use for development, would they?

Other barriers for developers include cost and even open source philosophy (but mostly cost). Microsoft is eliminating this obstacle with their WebSite Spark and BizSpark programs. The philosophy argument is addressed by licensing some Microsoft tools and libraries under Microsoft open source licenses (which include BSD-like and GPL-like licenses).

There are many other reasons why this summit is good for Microsoft, but I’ll end with a third one for this post. In the spirit of openness and transparency, open source communities tend to be very vocal and honest, often brutally honest. So, why would Microsoft invite a room full of PHP developers, where the common laptop present will be running Mac OS X, with a few Linux laptops sprinkled in the room, and even fewer Windows laptops? Our community doesn’t hold back with our opinions. That’s why. Each person in the room has ideas of how Microsoft can be better community citizens, provide better and easier to use products for developers, and improve support for PHP on Windows. We may not use that platform, but we all have ideas for how it can be better. I don’t think Microsoft is kidding itself that it will convert us to its platform, but I do think they value our opinions and presence because our feedback will make their products better and we’ll communicate the experience back to the greater PHP community (i.e. through blog posts such as this), improving their image.

Do I think Microsoft has done anything positive with our feedback? You bet. In the years since the Web Dev Summit was first held in 2006, we’ve seen improvements to FastCGI in IIS and the introduction of the open source SQL Server native driver for PHP. I believe these improvements are direct results of the Web Dev Summit. And there are others. This year, the focus appears to be on developer tools, so we’ll be having in-depth discussions on typical workflow and processes for developing a PHP project from start to finish. If you have suggestions for how Microsoft can improve their tools for PHP developers, let me know, and I’ll pass them along.

Finally, I’ll leave you with this thought. Microsoft has seen many changes over the years. They are a behemoth of a company, and my perspective now is that there are two types of people in the company: the big company corporate types who are still convinced that closed and proprietary is the way to protect their products, brand, and customers and, on the other hand, the newer generation of prod

Truncated by Planet PHP, read more at the original (another 1126 bytes)

Steve Holden: Comments or Not? Public or Private? Relevant or Irrelevant?

Recently I heard that some people aren’t happy about changes made to PyPi, the Python Package Index. As far as I am aware there is only one person who has been working on that application recently, and that’s Martin von Loewis. Martin, last year’s winner of the Frank Willison Award, is a Director of the PSF and someone who works tirelessly at various aspects of Python — many of them not particularly rewarding. As with many open source activities it is (I assume) a labor of love.

Recently Martin updated the Package Index to allow users to leave comments, and it appears that this innovation has been contentious. As a result of the rumblings Martin created a poll to determine whether the feature should continue in its present form or be modified in various ways. Here are the results as at the time of this writing:

Allow ratings and comments on all packages (status quo)					223
Allow package owners to disallow comments (ratings unmodified)					137
Allow comments, but only send them to package owners (ratings unmodified)					33
Disallow comments (ratings unmodified)					24
Disallow ratings and comments (status three months ago)					88

This is all very well, but unfortunately it appears that PyPi is now boxed into a corner. Even if the most popular option is implemented (retaining the current situation, where the newly-added rating and comment feature is allowed on all packages) this guarantees that a majority of those voting will have their favored option rejected. I suppose this demonstrates that you can give people too many choices.

My own discomfort with PyPi goes rather deeper. While I think that it’s great that we have a central repository to support setuptools (even though release 0.6 is now three years into its release cycle and onto its e leventh release candidate) and now distribute, I would like to see it become much more usable than it currently is. It would be easy to see this as an attack on the implementers and maintainers (which it is not intended to be: the maintainers of all the software I have mentioned have done valuable work that I could not). Honestly, it isn’t.

In reality I think it would be good if they had more help. Particularly the kind of help that let them package the facilities this excellent tool PyPi provides, in a much more obvious way. Even if this means complaining about the way things currently are.

Almost as a side note, I ended up following a twisty little maze of (web) passages all alike which finally led me to the Python issue tracker. Since it showed an apparently remembered login name and password I assumed all I had to do was click the Login button and all would be well, but apparently not. So I did what any user would do, and followed the Lost your login? link.

Alas, neither my email address nor my user name was recognized on that page, so I decided the only thing I could do was to register an account (even though I know I have submitted bugs in the past). So I went through the registration process only to be presented with the following unhelpful message:

OK, so what the heck is all that about? How am I now supposed to proceed if by chance I have burning information about a bug in the Python system? I have said before, and I will say again, that as an interface between Python’s users and its developers the issue tracker sucks. I am sure it is very useful for the developers, but as an input collection mechanism it seems to be only slightly less valuable than a customer service desk staffed only by a notice reading “go away” (I am exaggerating for dramatic effect here).

[Edit: this was apparently a bug, which has now been fixed at least for the Python bug tracker.]

I suspect that what is needed here is the e-mail equivalent of a help desk, where people with no knowledge of the infrastructure can exchange messages with a team of real human beings who know what the score is and can make any necessary inputs to the issue tracking system on their behalf. Call them user proxies, if you like. I am aware that in the high-tech world of open source this may be seen as a heresy, but people still have their uses, dammit, and they clamor to be useful even as the capitalist world declares them redundant by the hundreds of thousands.

Now I know before I post it that some people are not going to like this article: they will either say that I shouldn’t be complaining if I’m not prepared to fix what I’m complaining about, or that I should not be making a noise about something that third parties will use as evidence that the Python world is in some sort of disarray. Frankly I don’t buy either of those arguments.

The Python world has recently gone through a long-drawn-out and extremely energetic discussion about increasing the diversity of the community. As an existing community we are fighting an uphill battle, because it’s even more difficult to change the constituency of existing communities than it is to recruit a diverse mix to new ones. Just the same this has had some very positive results, not least the publication of a diversity statement that I think the Python Software Foundation has every right to be proud of — it might seem like a simple piece of text, but it was a hard-won development that even cost us the resignation of a member.

Yet despite all that work, we apparently haven’t yet got to the stage where the Python community includes people who can look at a less-than-optimal interface and say out loud “we need to do something about this”. I don’t know if this is because we are too close to PyPi to be able to acknowledge its faults, or because people fear hostile responses if they make negative comments about the infrastructure, or (perhaps most likely) because they don’t want to offend those who have invested their time and effort into producing something, at least, which is more than most of us do. I do know that it frustrates the hell out of me.

So let me put a public stake in the ground here. I have visited a number of local Python user groups in the past year (the first PSF chairman to do so, as far as I can tell). Almost everyone I have spoken to along the above lines has been enthusiastic about making things better, and willing to volunteer to help make the necessary improvements. So now I need to hear from the broader Python community about what’s “wrong” (less pejoratively: what we should change to make things better). This means you.

The Python Software Foundation is currently looking quite critically at next year’s activities and the budget to support those activities. If we are going to make a real difference to the perception of Python and to its adoption as a serious IT solution to a broad range of problems then we need broad involvement from the whole community, not just the PSF membership. I am investigating a number of ways in which the PSF could encourage a broader involvement, and it would be helpful at this point if there were general evidence of a desire by non-members to get more involved in Python: not just its development, but its community.

If this piece isn’t enough to get a decent discussion going then I suppose I should just resign as PSF chairman and look elsewhere for a community that gives a damn. I honestly don’t think that will be what I need to do. I’m really hoping you guys don’t let me down here.

Comprehensible Code – PHP Advent

“Any fool can write code that a computer can understand. Good programmers write code that humans can understand.”

— Refactoring: Improving the Design of Existing Code, by Martin Fowler.

Reading of any sort is a difficult and high-effort task. Human beings need years of training to learn the basics of reading, and more years after that to master comprehension of the written word. Once you have learned how to read, it’s easy to take it for granted, but it remains a difficult task, one that requires effort and concentrated attention. Reading for retention and comprehension is especially hard work.

Now, think of what it takes to read code. Not only do you need to understand the programming language, you also need to understand the commonly-used patterns and structures of that language. Every programmer is an author, potentially with his own idioms and expressions and almost certainly with his own style. Programming languages are not as nuanced and interwoven as natural languages, but they still require effort to interpret and understand.

Effort vs. Reward

Reading code feels unproductive. In reading, you may be gaining knowledge about a program, but you are not creating anything new. At best, you are comprehending the previous work of someone else. To a developer, especially one who thinks he is being paid just to write code, the level of effort involved in understanding the work of another developer seems like a horrific waste of time. The high-effort, low-reward feedback loop is frustrating.

Alternatively, the effort-to-reward feedback loop for writing new code is very short and feels very positive. It’s much less frustrating than trying to understand the work from another developer, because you are the developer. It feels immediately productive, because every line you write is something new you can point to as the result of your efforts. This kind of instant gratification is hard to resist.

Code as Communication

A large part of the problem in reading code is that most programs are written in the moment, not thinking ahead, and not thinking of the other developers who will have to read the program. It is natural to think of the program as being for the computer, but this is not entirely the case. As a developer, you have to deal with two readers: the computer, and other developers. Your programs are a medium for communicating, indirectly, with other developers. Code is a conversation between you and the developers who have to work with it.

For other developers, reading your code is hard work. To them, reading your code is a learning exercise. They have to figure out what problem you are trying to solve, what you are doing to solve it, and why you are taking a particular approach. Once you realize that reading code is a learning exercise, you can begin to appreciate that you should write your code as a teaching exercise so they can learn more quickly. This may be more work for you, but it is the high-reward kind of work that developers like.

In short: when writing code, remember the poor bastard who will have to read your program. That poor bastard may be you, six months from now.

Toward Better Communication

What can we do to make our programs easier to comprehend? There are many volumes on this subject, such as Code Complete. There is little I can add to these technical treasures.

However, in addition to the technicalities of code organization, there are many softer guidelines that make a great difference in comprehensibility. Think of these softer styles as making the difference between reading an Army technical manual and a good tutorial. The technical manual may have perfect grammar and structure, but lacks comprehensibility, whereas the tutorial has good grammar and good style.

Here are three communication measures you can adopt to improve readability and ease-of-understanding in your own work:

Adopt a coding style standard already in use by others.

I have long been a proponent of shared coding standards. In a way, using a shared standard is a variation on Jakob’s Law: “Users spend most of their time on other sites. This means that users prefer your site to work the same way as all the other sites they already know.” The same thing applies to code; if your code is styled and organized in a common fashion, you (and other developers) can read it with much less cognitive load.

I am a fan of the PEAR style guide; I gave up my own style long ago in favor of it. When comparing the PEA

Truncated by Planet PHP, read more at the original (another 3003 bytes)

Simon Wittber: Symbols in Python

Wikipedia defines a Symbol (as used in Lisp):

A symbol in the programming language Lisp is a primitive data structure that has a name. Symbols can be used as identifiers. Symbols are unique in a namespace (called package in Common Lisp). Symbols can be tested for equality with the function EQ. Lisp programs can generate new symbols at runtime. When Lisp reads data that contains textual represented symbols, existing symbols are referenced. If a symbol is unknown, the Lisp reader creates a new symbol.

I’m not overly familiar with Lisp, however I have done some work with Scheme; and an explicit Symbol type is something that I sometimes miss in Python. Do you ever find yourself defining classes to be used as global constants, so that you can use the identity operator? Perhaps something like this:

class START: passclass QUIT: pass

if something is QUIT: exit()

Symbols offer a better alternative to this, so I decided to implement a Symbol type in Python, which offered some of the features of a Lisp Symbol.

import sys 

class Symbols(object):    _symbols = {}    def __repr__(self):        return "<SYM %s>"%(self.name)

    def __getattr__(self, name):        s = self._symbols[name] = self.__class__()        s.name = name        self.__dict__[name] = s         return s

    def __getitem__(self, name):        return getattr(self, name)

s = sys.modules["symbols"] = Symbols()

How is this module intended to be used? Try this:

>>> import symbols>>> symbols.START is symbols.QUITFalse>>> symbols.START is symbols.STARTTrue>>>

The symbols module contains every possible Symbol, and can be used as simple set of constants… but it can also do more than that.

>>> symbols["START"] is symbols.STARTTrue>>>

Symbols can be accessed by a string name, which lets you use different characters in a Symbol name, and provides a convenient method for creating new Symbols at runtime.

The last requirement is for Symbols to be unique within their own namespace. Our symbols module can support this too.

>>> symbols.Foo.Bar.Foo is symbols.FooFalse>>> symbols.Foo.Bar.Foo is symbols.Foo.Bar.FooTrue>>>

This feature allows you to have an nested set of Symbols which retain their identity wherever they’re used in your program.

Ned Batchelder’s blog: Relaxed muscles in motion

I’m casual friends with a yoga student and teacher on Facebook, and he
recently posted a video. It’s a yoga teacher demonstrating two extremes of
bad form, and the happy medium:

I almost didn’t click on the video at first, because there’s a lot of stuff
that goes by on Facebook that I don’t look at. But my friend described it as
funny, and funny is a prime motivator for clicking.

And the video is funny, because David Swenson does a good job mocking his
bad students. But the thing that stuck with me was his “happy medium”
demonstration, and just how smooth and relaxed he was while moving far more than
most people do.

His motions have stuck with me, and I’ve been trying to be aware of tension
and relaxation in my own muscles. I know it’s not why Ross posted the video in
the first place, but you never know where you might find inspiration.

One simple thing: I try to take my hands off the steering wheel when I come
to a stop at a red light and just breathe deeply. Lord knows one place we
could use more relaxation is in the car…

CodeWorks Wrap-up – Ben Ramsey

I never wrote about days 13 & 14 of CodeWorks, nor did I post the slides on October 7, like I promised to attendees of my talks. After CodeWorks, my website underwent weird spikes in traffic, causing it to be extremely slow. I thought the problem was DreamHost, so I moved everything to a slice at Slicehost. Long story short, my slice kept crashing, so I moved everything back to DreamHost after several weeks of intermittent uptime to let them deal with the problems. That’s what delayed my posting, and I apologize to those who have been looking for the slides.

To sum up CodeWorks New York, I would have to say that the energy and enthusiasm at the New York conference was, by far, the best of all seven cities. The turn out was great, and the hallway track was the best yet, with myriad discussions extending from the talks. I’m not sure what made the difference, but it was definitely the best stop.

Seven cities in fourteen days. CodeWorks was a whirlwind tour, and I was privileged to be a part of it. It was a pleasure to meet PHP developers in each city and to talk with those who lead user groups, are starting a group, or are thinking of starting one. And the talks were excellent, presented by some of the best and brightest in the PHP community. It was an awesome experience, and I’m glad we were able to take the conference to developers rather than expecting the developers to come to the conference. Though some cities had low attendance, the quality of each event was never lessened. If the conference continues next year, I think we’ll see more attendees in each city.

Yes, I would do it all again. So, I hope Marco sees fit to organize it next year, or at least, every other year.

I blogged every city we visited. If you’re interested, here are those posts:

As promised, here are the slides for my presentations (finally):

I hope to see you next year!

IronPython-URLs: Gestalt 1.0 and the Gestalt Widget Pack

Gestalt is a project by Mix Online to use Silverlight and the Dynamic Language Runtime to allow you to script web pages with Python or Ruby instead of with Javascript.

The Gestalt Project

DLR.js is a library released by a collaborative effort between the Dynamic Language Runtime team and MIX Online Labs. This JavaScript library allows you to write Ruby, Python & XAML code in your (X)HTML pages. It enables you to build richer and more powerful web applications by marrying the benefits of expressive languages, modern compilers, AJAX & RIAs with the write » save » refresh development model of the web.

Gestalt has reached a significant milestone with the release of version 1.0 and a widget pack. It has matured to the point where you can do really crazy things like run Rails *in your browser*. Probably not specifically useful, but it shows what it is capable of:

Introducing Gestalt 1.0 and the Gestalt Widget Pack

A few months ago, we released Gestalt beta as a MIX Online lab. Gestalt began as an exploration—a way to bring Ruby and Python to the web browser. Today, we’re delighted to announce that Gestalt has been updated to version 1.0. It’s now part of IronRuby 1.0 and IronPython.

What’s new in Gestalt 1.0? Gestalt Beta — plus more!

Supports bundling of Ruby and Python files using each language’s convention. You can now (for example) package and run Rails on your client!

Allows you to dynamically load assemblies (only downloads what you need)

Integrated with the Dynamic Language Runtime
Simplified and streamlined model for creating Gestalt apps.

No jQuery dependency.

Support for remote references to Gestalt

Visual Studio debugging support

A browser console for debugging and manipulating Gestalt

Rich error reporting

Built-in support for loading external assemblies and content

Support for running multiple instances of Gestalt on the same page

They also have a longer blog entry discussing the thinking behind Gestalt and what it makes possible. Perhaps worth drawing out from this article is the following: “By adding a <script>
tag to the top of your HTML file, you can automatically enable use of HTML5-compatible video and audio tag syntax.“

Gestalt Grows Up

Last week, we discussed the fact that Microsoft invests heavily in both HTML5 and Silverlight, two technologies that other companies would have you believe are mortally opposed. Our commitment to both was underscored this week by our announcements about IE9 and Silverlight 4.

When we launched Gestalt beta less than 4 months ago, our goal was to demonstrate a really simple idea: that a proprietary plugin like Silverlight complements and advances the standards-based web. With today’s launch of Gestalt 1.0 and the first few widgets in the Gestalt Widgets Pack, I’d like to drill deeper into this underlying philosophy of Gestalt.

Thomas Vander Stichele: quick hacks are hard

The good: in around 5 hours of coding (on two train and one plane trips) I knocked together a proof-of-concept traffic redirector for our platform, which understands incoming requests, maps them into client groups, then makes routing decisions by group to any of our sites based on a policy (least cost, geographically closest, …) In addition, I wrote a simulator that replays actual request log lines, and is able to then track the bandwidth used by each client group and each site, and even able to dump it to an .rrd file for later graphing. Not bad at all for a quick hack. Python is awesome when it needs to be.

The bad: some binary tree algorithm I use to be able to get a sorted list of simulated events seems to crap out currently at about 1000 request lines with a ‘Maximum recursion depth exceeded’. Last time I asked our database guy, I think we had about 10 million lines a day.

I don’t think my simulator is ready for prime-time just yet…

PHPBenelux Conference 2010 – Stefan Koopmanschap

After a lot of hard work, a very tough selection after a successful Call for Papers, I am very happy to announce that the PHPBenelux Conference 2010 website is now online, and speakers will be announced over the coming days.

Eli Bendersky: Book review: “The Practice of Programming” by Kernighan & Pike

TPOP is a typical “how to be a good programmer” book, somewhat similar to Code Complete, with a little bit of Programming Pearls mixed in. What really sets it apart, IMHO, is its authors – the combined rep of Brian Kernighan and Rob Pike is very hard to beat!

I’m saying it’s similar to Code Complete because mostly the same subjects are covered, just in much less length. Programming style, algorithms, interfaces, debugging, testing, portability and other subjects are covered in a light and flowing manner. The advice given is solid, the examples are relevant and interesting and valuable insights are shared. This isn’t the first time the book falls into my hands (I flipped through it a few years ago) and I still found it very interesting.

Any programmer should read at least one book like TPOP. In addition to learning one’s languages and environments, it’s very valuable to read something about the process (or practice) of programming as well. For this purpose, something short and lightweight like TPOP or The Pragmatic Programmer is recommended. Tackling an encyclopedia like Code Complete is a feat for the most hard-core fans of the trade only.

The only criticism of TPOP is that it feels a bit dated, although written only 10 years ago. I think that the age of the authors shows – they are around since the early days of C and Unix, back when Awk was the coolest kid on the block. Sure, they mix some C-ish Java code in for the hype, but the book still feels like something written in the 70s.

All in all though, I do recommend it.

Book review: “Internetworking with TCP/IP, Vol III” by D.E. Comer, D.L. Stevens Full book name: “Internetworking with TCP/IP, Volume III – Client-server…
Book review: “Rapid GUI Programming with Python and Qt” by Mark Summerfield Mark Summerfield has a lot of Qt experience, having worked…
Book review: “Dreaming in code” by Scott Rosenberg Secondary title: “Two dozen programmers, three years, 4732 bugs, and…

keep looking »

Enterprise LAMP