Enterprise LAMP

Marpa: Practical General BNF Parsing

With a regular expression engine, there
are expectations.
You feed a regular expression to the RE engine, it parses with it.
That simple.

A general BNF parser is one which fulfills the same
expectation for BNF.
Write your language in BNF, you got a pa…

Hello, Analog – Chris Shiflett

A few months ago, I was on top of the world. The place was called Sjónarsker, and the view was breathtaking. It was the third day of a road trip around Iceland with my friends Andrei and Helgi, and I had just shared some big news with them. I was leaving my former company and starting something new.

They wanted to know what I would be doing next, and although I didn’t know, I did have an answer. “Good people. Good work.” These four words became a personal mission statement in the months that followed — something to provide focus and clarity.

Good people and good work go hand in hand. I remember how much I enjoyed working with Jon Tan and Jon Gibbins a few years ago when redesigning my blog. The experience is perhaps best remembered with a comment I made shortly after we finished:

Working with both Jon Tan and Jon Gibbins was a joy; not only do they possess the skills necessary to shape ideas and bring them to life, but their rich personalities and keen sense of humor makes the entire process a lot of fun.

Good work isn’t work; it’s fun. To do our best work, we need to love what we do. We need to surround ourselves with good people who appreciate good work. We need the freedom to break boundaries. We need to be inspired. Above all else, we need to be happy.

I’m very happy to introduce Analog, a co-operative of web designers and developers:

Analog is a company of friends who make web sites. It’s a co-operative where imagination, design, and engineering thrive; good people doing good work.

Allow me to introduce you to my friends.

Alan Colville
Alan is a user experience designer who has been making the Web a better place for more than a decade, helping companies like BlackBerry, Vodafone, and Visa. Although his professional experience is impressive, we’re more impressed by his achievements on a bicycle, like being the runner-up at the Kona Cheddar Bikefest 2009.
Andrei Zmievski
Andrei is one of the best developers I know, and if you use PHP, chances are you’ve encountered his work. He’s a member of the PHP Group, started PHP-GTK, helped create Smarty, and is the architect of the Unicode and internationalization support in PHP 6. In fact, when Yahoo switched to PHP, they hired Andrei. He’s also a talented photographer and brewer, and 100 days from now, he’ll be running the Marathon de Paris.
Jon Gibbins
Jon, also known as Gibbo or the Prince of Kindness, is a multi-talented web developer and accessibility aficionado who has helped companies like Travelodge and National Geographic. His mastery of html, CSS, JavaScript, and PHP is truly inspiring. On occasion, he suspends his kindness long enough to play a mean guitar.
Jon Tan
Jon is the best designer I know. I first encountered his work long before I knew him as a person, and I still feel extremely lucky to know him. His love of typography is evident in all of his work, and he’s one of the only members of the International Society of Typographic Designers who focus on typography for the Web. He’s also a former journeyman in the Guild of Indian Ocean Octopus Fishermen. I’m pretty sure the guild is made up, but the stories are real. :-)

Co-operatives are organizations that adhere to the co-operative principles. Jon’s description of his personal values — values we all share — helps explain what we’re about:

I believe that everyone working on a project should profit equitably from it according to the scope of their

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

IronPython-URLs: A Good Mix 34: Silverlight Logging, WPF and NotifyIcon, more Python and Ruby and pickling Python books

Another collection of IronPython and DLR related articles from around the web. A fine way to end 2009.

A nascent project to Port Log(4|5)J from Java to C# with the goal of usefulness in Silverlight, especially for IronPython.

 Two Japanese blog entries, both by sasakima-nao. As with previous entries the code examples are very readable. The first is a simple WPF picture viewer (nice penguins) and the second shows how to create a NotifyIcon and ContextMenu in the taskbar (with Windows Forms classes).

This blog entry is in Russian, but I think there are enough code examples for it to be useful for those of us who don’t speak Russian. As I’ve mentioned before the promise of the Dynamic Language Runtime is that dynamic languages can interoperate and share libraries. This is exactly what this blog entry shows: using the Ruby soap/wsdlDriver from Python.

The cool thing is that this is done with a helper / wrapper library, that looks like it could be used to expose virtually any Ruby module / class that can be accessed through IronRuby to IronPython. Using his ruby module, the code looks like this:

from ruby import _import_, get_class
_import_(’soap/wsdlDriver’)
Soap = get_class(’SOAP::WSDLDriverFactory’)

client = Soap(’http://localhost1/Service1.asmx?WSDL’).create_rpc_driver()
client.HelloWorld(None)

Marcus McElhaney has discovered IronPython and likes it. The reasons he gives are:

1. I can very easy use everything I know about the .Net Framework, VB.Net, and  C#
2. I can run IronPython in Visual Studio
3. I can reference ESRI’s  ArcObjects libraries in  Visual Studio and IronPython

What’s even more gratifying is that he has been exploring IronPython through IronPython in Action and likes that too. A slight misspelling gives rise to my favourite quote about IronPython in Action:

IronPython In Action is probably the best Python book I have ever pickled up because it also explains a lot of not just Python but also about .Net.

If any book deserved to be pickled up, this is it… Have a great 2010.


Steve Holden: Open Source Documentation, Again

I had a whole blog entry written, but sadly the new and “improved” Blogger application appears to have eaten it. Personally I don’t think they have improved the application, as ^Z after setting something to a block quote now appears to delete the complete entry contents, the preview is way less friendly in the new popup format, and the editor icons don’t seem as intuitive as they used to. Overall I think I’d rather go back to the previous version, but there doesn’t seem to be any way to do that.

Anyway, to cut a long story boring, I just wanted to point out that when I went to update my Cygwin installation (hoping that Python 2.6 and/or 3.1 would now be available, which sadly they aren’t – where’s Jason Tischler when you need him?) I got a parse error on the setup configuration file. No biggie, the setup program even pointed out that I probably needed to download a new copy, and when I did so the updated copy told me to read the Cygwin documentation to find out what I needed to know to update from 1.5 to 1.71 (I presume 1.6 was omitted for some reason).

Sadly when I went to the Cygwin home page the only relevant information I see is “PLEASE read the new User’s Guide before upgrading your Cygwin installation to 1.7. You’re avoiding trouble.”

This is OK, but when I follow the link to the users’ guide I get a list of three different possible formats plus links to two different quick start guides and another link to Setting Up Cygwin. It’s only by clicking one of the users’ guide links that I finally discover the link, in the table of contents, to What’s new and what changed in Cygwin 1.7. Guess what? None of the information in there relates to upgrading from an earlier version, so I am left with the only hint being the note at the start of the home page that says

Please note that the update from Cygwin 1.5.x to Cygwin 1.7.x might require some manual changes afterwards. Most notably the mount point storage has been moved out of the registry into files. User mount points are NOT copied into the new user-specific /etc/fstab.d/$USER file. Rather, every user has to call the /bin/copy-user-registry-fstab shell script once after the update.

Now I don’t want you to think that Cygwin’s documentation is lousy. In fact the situation might seem less problematical if the documentation were worse, but generally Cygwin is up there with Python and Django in terms of the quality of its documentation. All of which only makes it seem more jarring that there is no specific advice to use migrators, even though the project home page seems to imply a) that there is, and b) that it’s important to read it.

Anyway, I am going to finish this post now, before Blogger decides it’s time to delete all my typing again. Happy New Year!

EDIT: Interestingly the original entry came through on Feedburner, but I decided to leave the revised entry as it was, modulo this edit. As is so often the case, a re-work improved the quality of the work.

Chris McDonough: View Dispatch Is Not An Adapter Lookup

In a podcast we
recorded yesterday, I held forth about the new features of the last
two repoze.bfg releases. One of these, new in 1.1, was the idea of
“view predicates”.

Now, the idea of a view predicate was not mine, it was Malthe Borch’s.
At the time, I was still wrapped up in the Zope-inspired worldview
that a view invocation is (by god) an invocation of a ZCA
multiadapter, QED, full-stop. Malthe figured out that it is useful
to look outside the idea of adaptation to resolve a request to a view,
and as a result I implemented view lookup in terms of view predicates
in 1.1; 1.0 lacked this feature. The epiphany is somewhat obvious in
hindsight, but at the time, it was not. I was well and truly wrapped
around the adaptation axle.

For those who don’t know, an “adapter” is a bit of code that converts
a set of input objects [I] to an output object O. The simplest
physical example of an adapter is the one we know and love: a power
plug adapter. Maybe one that converts a US-style two-pronged power
plug to a “proper” mains plug like they use in the UK. Other stilted
and trivial adapter analogies exist, I’ll skip them here. Google for
“Zope adapter”.

In Zope (and BFG, and Django) terms, a “view” is a bit of code invoked
as the result of a particular request. It’s called a “controller
action” in other framework religions.

In terms of view dispatch, Zope uses a combination of graph traversal
and an adapter lookup to find a view. Rather than using some ordered
set of URL match tests like many other web frameworks, Zope encodes
all knowledge about which view should be invoked in all particular
circumstances within a given application as a set of adapter
registrations. When a request enters the system, traversal is
responsible for finding a “context” object and a “view name”. Using
this context object, this view name, and the request object it does a
“multiadapter” lookup something like this: please find me a view
adapter for this kind of context and this kind of request with this
name. Ex.: ((context, request), view name) -> view object.

While I’m a big fan of this style of dispatch, real-world requirements
stretch its applicability. It was always pretty odd to need to attach
an interface object to a request in order to convince the view
machinery to do something different in some circumstance; it got truly
weird when Zope started to support persistent registries that allowed
you to make different view registrations in different contexts.
Entire subframeworks of various Zope subsystems and offshoots exist
just to manage the results for adapter and utility lookups related to
requests and contexts. I fear it may all be for naught.

What Malthe figured out is that view dispatch is not just an adapter
lookup. While adapter lookup can help speed things up, there’s just
not enough value in the adapter lookup machinery to spell all the
query axes in terms of interfaces, as required by zope.component. For
example, it makes a hell of a lot more sense to register a view
callable that will be invoked in a circumstance like so:

  request.method == 'POST'
  'application/json' in request.accept

Than it ever would to register something in terms of interfaces, like
Zope makes you do, ala:

  providedBy(request) -> IPostRequest, IAcceptApplicationJSON

I mean, literally, it’s just not really possible to anticipate all the
interfaces you might need to attach to a request in order to provide a
vocabulary that allowed you to compose interfaces in enough
combinations for such a system based on interface lookup to work.
Even if you could, who would understand it after you created it?

With view predicates in BFG 1.1+, it becomes quite easy to register
view callables for very specific circumstances that would be extremely
difficult (or maybe impossible) to spell if you treated view lookup as
only an adaptation problem. For example, using the containment view
predicate in BFG, you can do this:

  <view
    for=".models.Entry"
    name="edit.html"
    containment=".models.Blog"
    />

The containment=".models.Blog" attribute is the important bit. It
says “only invoke this view when the context object or any of its
parents is a Blog object”. This solves a whole raft of problems for
UI, where you want to use the same kind of object in two places (an
“Entry” object) but you want its edit view to be slightly different in
two different “sections” of a site: maybe one view when we’re in the
Blog section, and another when we’re in a Calendar section. This sort
of registration is not possible in bare Zope, and adaptation alone,
at least in the context of using a single adapter registry, cannot do it.

I don’t think we can continue to treat view dispatch in the Zope world
as a bare adapter lookup; it’s just too limiting. In BFG 1.1+ we do
not. Using a pattern much like Zope’s we use a multiadapter lookup to
find a “view” object. However, the view object that is found is often
a “multiview”. A multiview is a collection of views with associated
predicates. Once a multiview is found and called, it evaluates the
predicates associated with each of its constituent view callables (in
a reasonably easy to understand order) to find the most specific view
callable; then it invokes that to obtain a response.

Essentially we use the adapter lookup machinery only as a speed
enhancement in this circumstance. The adapter lookup gets us
“in a ballpark” where we can perform fewer predicate evaluations
to find “the best” view callable. It would be possible to implement
it without doing any adaptation at all, it would just be a lot slower.

Other predicate attributes exist for use in this way: route_name, request_method,
request_param, xhr, accept, header, path_info. In the very latest release (1.2a9),
there is even a “custom predicate” predicate, which allows you to provide a
callable that returns true or false for an arbitrary circumstance so you
can create your own predicate logic. These can be combined arbitrarily
to specify an extremely granular set of circumstances without any interface
foolery.

Personally, I think view predicates are a pure win, and I think their existence
demonstrates why bare adaptation is not ideal for view lookup. I might
even take that a little further: it would also be useful to be able to look up
other things (such as utilities, and other code) using the same set of
predicates. If this becomes true, I think the adaptation worldview as
“from interface X to interface Y” as a fundamental assumption begins to look
pretty anemic.

Simon Willison: Web Sockets in Tornado

Web Sockets in Tornado. Bret Taylor has a simple class making it trivial to experiment with the Web Sockets protocol (now shipping in Chrome) using the scalable Tornado application server. He also raises the million dollar question: what will existing load balancers and proxies make of the new protocol?

Lawrence Oluyede: Social programming

Lately I’ve been finding myself amazed about the social turn that programming has taken in quite a while.

I started growing as a software developer thanks to the Internet, it and the people on mailing lists/forums/irc have shaped my skills, career and made me discover a lot of great things. I owe the Internet a lot. As Tim Bray says in his After Branding essay:

You are whatever the Net says you are. Deal with it.

It is pointless to start talking about what good open source and version control tools have done to the social side of programming because it’s there to see for everybody. Websites like Sourceforge and Freshmat were everything we talked about in the old days.

Nowadays Distributed version control is taking over and the reasons why are clear: we need to be more and more social and what better way to exchange knowledge than to distribute code?

If I could I’d change name of those tools to “social version control”.

What I love about sites like GitHub and Bitbucket is that they are trying to build real social networks around source code, every developer’s currency. I love it. The what is not new but it’s the how (like how easy it is to contribute) that changes everything.

I look forward to social programming.

ps. on Twitter there is an amazing community of software developers exchanging small tips or links every day. You MUST be on Twitter, really. I am.

Midgard in 2009 – Henri Bergius

Vali raising a toast2009 was a pretty active year for the Midgard content repository project, and so it is good to take a look at some of the highlights:

Happy new year to everybody in the Midgard world!

Steve Holden: Links for 2009-12-30 [del.icio.us]

Ted Leung: 2009 in Photography

Here’s a roundup of what I saw through the lens in 2009.

January

This year I did a lot more work with local and regional dancers. Here’s a danceseattle rehearsal shot.

danceseattle rehearsal

February

I continued my role as the official photographer for Bainbridge Island Chinese Connection’s Chinese New Year Celebration.

Seattle Chinese Orchestra

March

I caught this shot of Guido van Rossum at PyCon by being in the right place at the right time. My camera was lying on the table next to me when Guido suddenly grabbed the Django Pony and started running down the aisle. He was moving fast enough that I had to snap off a bunch of frames to catch him in focus.

PyCon 2009

April

April was busy dance month. The Olympic Performance Group put on “The Toymaker’s Doll” (also known as Coppelia).

OPG Toymaker's Doll 2009

danceseattle had their first ever performance.

danceseattle Looking Glass Glimpses 2009

For the first time in a long time, I actually was able to show up to a Seattle Flickr Garage shoot.

UW Garage Shoot 9

May

May is when the weather in the Seattle area starts to get decent, so I was able to get some nature subjects in front of the lens.

Focus stacking experiments

Memorial Day Low Tide Beach walk

June

I headed to San Francisco for JavaOne in early June.

CommunityOne 2009

I finished out June with Bainbridge Ballet’s end of year recital.

Bainbridge Ballet Recital 2009

July

The Bainbridge Island Fourth of July Parade is always a family and photographic staple.

Bainbridge Island Fourth of July Parade

Also in July, we had the first guinea pig born in our house.

The latest addition to the family

August

I made it to a second Seattle Flickr garage shoot.

UW Garage Shoot 10

September

Senior pictures for Bainbridge High School are due at the end of September, and I did 4 sessions in the space of 12 days or so.

Blake - Class of 2009

Blake - Class of 2009

Stefan - Class of 2010

Matt - Class of 2010

Michael - Class of 2010

October

School was in full swing in October, and one of the science lessons that Julie did with the girls involved extracting DNA using Bacardi 151 rum.

Homeschool: Extracting DNA with Bacardi 151

November

This year was the 10th Anniversary of the Apache Software Foundation (and my involvement with it). I did take a few shots while I was at ApacheCon.

ApacheCon US 2009

ApacheCon US 2009

I was also fortunate enough to get a slot to J. Mark Wallace’s US Meetup Tour when it hit Seattle.

Images from the Mark Wallace US Meetup Tour

December

Photographically, December is dominated by the Olympic Performance Group’s production of the Nutcracker.

OPG Nutcracker 2009

OPG Nutcracker 2009



keep looking »

Warning: include(/home/remarkwit/enterpriselamp.org/wp-content/themes/Enterprise_LAMP/r_sidebar.php) [function.include]: failed to open stream: No such file or directory in /home/remarkwit/enterpriselamp.org/wp-content/themes/Enterprise_LAMP/archive.php on line 23

Warning: include() [function.include]: Failed opening '/home/remarkwit/enterpriselamp.org/wp-content/themes/Enterprise_LAMP/r_sidebar.php' for inclusion (include_path='.:/usr/local/lib/php:/usr/local/php5/lib/pear') in /home/remarkwit/enterpriselamp.org/wp-content/themes/Enterprise_LAMP/archive.php on line 23