Well… they talk not too much about Scala or even about topics related to Scala. So I don’t recommend this podcast for ones who wants solid and concentrated insights on the topic :-).

Regarding last episode. It was an interview with Heather Miller, she’s stated to be “New Documentation Czar” — she’s now ruling an effort to provide more solid and more deep covered documentation for Scala programming language. And again I’m surprised — they didn’t even mention Sphinx, the current state-of-art of documentation tools, which is sad… I really wish Scala language and its standard library be documented with the use of Sphinx.

• MVC & MVVM architecture patterns for client-side development… ok
• Design patterns for JavaScript applications… ok
• Dependency management… ok
• JavaScript templating… ok
• Cross-browser persistent storage… ok
• Feature detection… ok
• Widgets & Component libraries… ok
• Unit Testing & testing environments… ok
• Build Processes, concatenation and minification… Ant.. wtf?!

So how such a piece of shit as Ant is happened to be used there… no excuse.

For the novice wishing to adopt Python in least possible time and quickly become productive I would recommend the following steps:

Tutorial

Tutorial given in Python docs is very good, you should just give a brief look at it if not reading it completely — it has many practical examples, which helps a lot to make a sense what the beast Python is.

Language reference

Sections 1 - 4 from The Python Language Reference. Section 3. Data Model is the most important one here. It gives a broad overview of how Python data types interacts with each other. Other sections can be read as needed — Python syntactical constructs are usually make sense from their analogues in other languages. Yield and with are the exceptions.

Standard library documentation

Python stdlib is the cause this language is so productive and popular. Read sections 1–5 from The Python Standard Library docs and keep an eye on a list of stdlib’s modules.

Common tips

A list of common tips at last:

• Use Python 2.x (where x is 2.6 or 2.7)— it’s still deployed much widely than Python 3.x.

• Follow PEP–8 styleguide, never step away from it!

• Defining class always subclass from object (assuming you’re using Python 2.x).

• Never write from somemodule import *.

• Always use virtualenv for developing with Python. It’s a tool for creating isolated Python environments.

• PyPi, The Python Package Index helps you to find any Python library you wish. Just use easy_install or pip command for installing from there.

The end.

Personally, I think Zope is excellent project which gave raise to the current state of the art of pythonic web frameworks — Pyramid.

Don’t miss the links at the end of the article to projects which also (as Pyramid and Zope do) implement object publishing via URL traversal — Fantastic and traject.

The points are:

• Why do we have to use module structure that reflects filesystem layout?

• Let’s better have database with plain functions and query it by some associated metadata fields.

This leads me think about Smalltalk programming language and how it manages source code — runtime image is really a database with classes and associated methods.

But how it works:

• Does it use some ranking algorithm for presenting content?

• What algorithm it uses for composing layout?

Interesting…

There’re primitive patterns (they act as building blocks), some of them are:

• Exchange — encapsulates a single piece of communication, it can has synchronous or asynchronous semantics.

• Message — a piece of data which represents some event or command.

• Channel — a route for exchanges.

• Message processor — its name says all about what it does.

• Filter — filters messages by some predicate.

Some more complex ones are:

• Message router — routes different messages to different channels.

• Aggregator — aggregates a some (defined via predicate) set of messages and processes it as a single message.

• Recipient list — provides multicast mechanism.

If you’re interested in full list of patterns, please see EIP reference or read the dedicated book on these.

The one implementation of EIP I was working with is excellent Apache Camel Java library. There’re many so-called “components” for Apache Camel, which provides adapters from/to various persistence mechanisms (relational databases, file systems, …), messaging solutions (AMQP, beanstalkd, …), web services and so on. Using such components you can compose them in different ways with help of internal fluent DSL. Better visit examples page for seeing how it works.

But I think that Erlang/OTP fits much better for this kind of things:

• Parallel runtime with preemptive lightweight processes with N-M scheduler (N number of processes maps to M number of OS-level threads).

• Isolated processes helps localize failures of independent exchanges.

• Process linking allows build sophisticated error handling and recovery strategies.

• Pattern matching on message structure makes code more clear and concise in comparison to dynamic type casting and nested if-statements in Java.

• OTP framework provides a solid foundation as a set of behaviours — process supervising tree, finite state machine, event listener and etc.

• Hot code reloading makes updates easy — while in-fly exchanges can use old code for processing, new ones can be processed by updated version of code.

In future posts I’ll try to provide implementation sketch and architectural overview of such a system. Stay tuned.

Update

Yes, I’m aware of Scala DSL for Camel (which seems abandoned for now) and more strong scalaz-camel library, moreover I’ve used Scala with Apache Camel and I should say — Scala makes my application’s code suck much less. But I’m also expect much more from applicaton written in such expressive and powerful language as Scala — (a) type safe routes, (b) redesigned core based on Scala concurrency primitives (maybe Akka actors) allowing to get rid of all this Java boilerplate and garbage.

While I understand I cannot gain (a) by designing such a library in Erlang — dynamically typed language — it makes more sense not to expect statical type checks in Erlang than to see runtime cast errors in such a language like Java or Scala beeing statically typed from the ground up.