Thanks to funding provided by the Friends of the Vancouver City Archives, we have been able to describe and digitize over one thousand of James Crookall’s images and make them available online.

James Crookall was born November 7, 1887 in Preston, Lancashire, and came to Vancouver as a child. Throughout his life, Crookall was an avid amateur photographer and an enthusiastic outdoorsman. He was an active member of the Vancouver Photographic Society and regularly exhibited his photographs in international salons. He died on July 27, 1960, and his fonds was donated to the Archives by Mrs. Doris Crookall in 1979.

Self portrait, 1938. Reference code AM640-: CVA 260-978.

As a young man, Crookall joined the Union Steamship Company of B.C. He served first as a Steward, then as a Clerk and was made Secretary in 1912. His photographs reflect an interest in maritime traffic and activities.

Captain Browne and Williams aboard S.S. Camosun, ~1918. Reference code AM640-: CVA 260-1090.

Man on ship’s gangplank, 1939. Reference code AM640-: CVA 260-1031

In 1907, he joined the 6^th Regiment, the Duke of Connaught’s Own Rifles, probably in the reserve unit, as he was still working for the Union Steamship Company. We have been told that he knew Major Matthews, the first City Archivist, and it’s possible he met him as a fellow member of the D.C.O.R.

During World War I, he served for two years with the Royal Flying Corps. Over his lifetime, he took many photographs of both military and civil aircraft at airshows.

Pilot of Aero Club of B.C. biplane (CF-ANN), ~1930. Reference code AM640-: CVA 260-359.

Stunt man with wings, 1937. Reference code AM640-: CVA 260-713.

After the war he resumed his career with Union Steamships. Crookall became Secretary Comptroller and was appointed Secretary-Treasurer in 1949. He retired in 1958 only a few months before Union Steamships ceased operations in 1959.

In addition to photography, Crookall had many recreational interests. He was an avid painter and a keen outdoorsman, regularly cycling or hiking many miles in search of subjects for his easel or his cameras. He was involved with a local group of amateur photographers called the “cycling circus”, which formed during the gas-rationing years of World War II and organized photographic trips by bicycle.

His photographs show an appreciation of geometry, light and shadow.

Architectural details of St. James Church, ca 1936. Reference code AM640-: CVA 260-430.

A metal staircase attached to a tank, 1938. Reference code AM640-: CVA 260-979.

His works also show a keen interest in people at work and play.

Shigeharu Nishihama repairing fishing net, Steveston, 1938. Reference code AM640-: CVA 260-944.

Woman at drinking fountain at the beach, 1937. Reference code AM640-: CVA 260-670.

Crookall used a variety of cameras and photographic media. He used glass plate negatives, nitrate film pack negatives and roll film in several formats including 35mm. He tried an unusual and early colour process called Dufaycolor, which was first used for motion pictures in 1932 and then for still photography from the mid-1930s. In this process, the film base was dyed with a fine pattern of red, green and blue lines which acted as filters. The result is a transparent positive image.

Rock Garden of Stanley Park, ~1930s. Reference code AM640-: CVA 260-1803.

Unidentified steamship, ~1930s. Reference code AM640-: CVA 260-1819.

The filter pattern can be seen on the photograph under magnification.

Dufay filter pattern on at 200x magnification. Detail from image of steamship above, reference code AM640-: CVA 260-1819.

We have curated a set of 81 of Crookall’s images on flickr. For all the descriptions and images, as well as the other materials in his fonds, take a look in our online search.

"""
An example of scheduling time-based events in the background.

Download the latest EUR/USD exchange rate from Yahoo every 30
seconds in the background; the rendered Flask web page can use
the latest value without having to do the request itself.

Note this is example is for demonstration purposes only, and
is not actually used in the real world. You should not do this
in a real application without reading Yahoo's terms-of-service
and following them.
"""

from flask import Flask

from twisted.internet.task import LoopingCall
from twisted.web.client import getPage
from twisted.python import log

from crochet import run_in_reactor, setup
setup()


class ExchangeRate(object):
    """
    Download an exchange rate from Yahoo Finance using Twisted.
    """

    def __init__(self, name):
        self._value = None
        self._name = name

    # External API:
    def latest_value(self):
        """
        Return the latest exchange rate value.

        May be None if no value is available.
        """
        return self._value

    @run_in_reactor
    def start(self):
        """
        Start the background process.
        """
        self._lc = LoopingCall(self._download)
        # Run immediately, and then every 30 seconds:
        self._lc.start(30, now=True)

    def _download(self):
        """
        Do an actual download, runs in Twisted thread.
        """
        print "Downloading!"
        def parse(result):
            print("Got %r back from Yahoo." % (result,))
            values = result.strip().split(",")
            self._value = float(values[1])
        d = getPage(
            "http://download.finance.yahoo.com/d/quotes.csv?e=.csv&f=c4l1&s=%s=X"
            % (self._name,))
        d.addCallback(parse)
        d.addErrback(log.err)
        return d


# Start background download:
EURUSD = ExchangeRate("EURUSD")
EURUSD.start()


# Flask application:
app = Flask(__name__)

@app.route('/')
def index():
    rate = EURUSD.latest_value()
    if rate is None:
        rate = "unavailable, please refresh the page"
    return "Current EUR/USD exchange rate is %s." % (rate,)


if __name__ == '__main__':
    import sys, logging
    logging.basicConfig(stream=sys.stderr, level=logging.DEBUG)
    app.run()

This is a short and unsorted collection of personal wisdoms that may help you improving your day and life as a software developer, freelancer, project manager or whatever.

You first, projects second

The first think that counts is you . You and your personal health should have the highest priority. Don't ruin yourself for whatever reason. Your health is your capital.

Don't be reachable at any time

Whatever position you have in a project: you don't have to be reachable at any time for any person. Give your working day a structure. Consider fixed working hours that you do not exceed. 

Avoid overtime

Overtime is a bad thing. Yes, things must be done at some point but constant overtime is bad for your health and mood - unless you are a coding maniac. 

Don't be a slave of your email client

Reduce to poll time of your email client to one hour or so - being interrupted while programming is a bad thing. 

Delay email replies

There are email client add-ons like SendItlater that allow you to answer to an email directly but defer the delivery to a some time in the future. This may slow down email ping-pong between and your customers significantly. 

Have separate email clients

For some projects (with lots of email during the day and night) I use a dedicated email client that I can close at any time. I use my standard email client to keep track of my private email and other project email (where I know that there will be only a few mails per day without a big risk of trouble)

Do not respond to all email the same day

If there is some email coming in the late afternoon and you can already smell the trouble by reading the sender or the subject: keep it closed and read it the other day. Do not ruin your last working hour and the rest of the day with trouble emails.

Smell the stress

It takes some experiences to notice when the project stress turns against you. Stress can have various symptoms and they are very individual. Personally I notice upcoming stress situation through problems with my stomach.

Get out of the stress

This is often easier said than doable in reality. But if often helps taking a break for an hour or two and doing sports. First it reduces my aggression level and gives me a more clear thought on some pending problems. Or if you can: take a day off and do something completely different.

Know your limits

Know yourself! You have to know where your personal limits are and how far you can go. While we are all getting older we have to recognize that we can not handle a workload as when we were ten years younger. It does not mean that we are less efficient and effective but we deal with workloads in a different way.

It is you that counts, it is your health that counts. So in order to avoid a burnout: you first, projects and customers second....

Test data generation is always a hot topic when it comes to automated software testing. One of my first assignments at 4teamwork was to help with the testing. In the process I was browsing through the test suites of some big projects they are working on and noticed a lot of similar code related to data creation:

1
2
3
4
5
6
7
8
9
10
11
12
13

dossier = createContentInContainer(self.portal,
                                   'opengever.dossier',
                                   title='Dossier',
                                   checkConstraints=False)

test_file = NamedBlobFile("lorem ipsum", filename=u"test.txt")
document = createContentInContainer(dossier,
                                    'opengever.document',
                                    checkConstraints=False,
                                    title=u'Foobar',
                                    keywords=[],
                                    file=test_file)
transaction.commit()

This is very basic object creation code and I’m sure many Plone developers have written a fair amount of it. While this gets the job done, there is a lot of noise, that we don’t need to have in every test.

I decided to use a basic implementation of the Builder Pattern to hide the noise in specific Builder classes and make our tests shorter and more expressive at the same time:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42

class DossierBuilder(object):

    def __init__(self, session):
        self.arguments = {"checkConstraints": False}

    def titled(self, title):
        self.arguments["title"] = title
        return self

    def within(self, container):
        self.container = container
        return self

    def create(self):
        obj = createContentInContainer(self.container,
                                       'opengever.dossier',
                                        **self.arguments)
        transaction.commit()
        return obj


class DocumentBuilder(object):

    def __init__(self, session):
        self.arguments = {"checkConstraints": False,
                          "keywords": []}

    def within(self, container):
        self.container = container
        return self

    def attach_file_containing(self, content, name=u"test.txt"):
        file_ = NamedBlobFile(data=content, filename=name)
        self.arguments["file"] = file_
        return self

    def create(self):
        obj = createContentInContainer(self.container,
                                       'opengever.document',
                                       **self.arguments)
        transaction.commit()
        return obj

We can now use our Builder classes inside our test-case.

1
2
3
4
5

from builders import DossierBuilder, DocumentBuilder

dossier = DossierBuilder().within(self.portal).titled(u"Dossier").create()
document = DocumentBuilder().within(dossier).titled(u'Foobar') \
    .attach_file_containing("lorem ipsum").create()

Already a big step forward! We have only defined two Builder classes, and we already notice some duplication among them. Defining a base class gives us a place to store the shared behavior:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36

class DexterityBuilder(object):

    def __init__(self, session):
        self.arguments = {"checkConstraints": False}

    def within(self, container):
        self.container = container
        return self

    def titled(self, title):
        self.arguments["title"] = title
        return self

    def create(self):
        obj = self.create_object()
        transaction.commit()
        return obj

class DossierBuilder(DexterityBuilder):

    def create_object(self):
        return createContentInContainer(self.container,
                                        'opengever.dossier',
                                        **self.arguments)

class DocumentBuilder(DexterityBuilder):

    def attach_file_containing(self, content, name=u"test.txt"):
        file_ = NamedBlobFile(data=content, filename=name)
        self.arguments["file"] = file_
        return self

    def create_object(self):
        return createContentInContainer(self.container,
                                        'opengever.document',
                                        **self.arguments)

Finally we hide the different Builder implementations and their instantiation behind a function. This allows us to change the Builders without touching all the tests that use them:

1
2
3
4
5
6
7

def Builder(name):
    if name == "dossier":
        return DossierBuilder()
    elif name == "document":
        return DocumentBuilder()
    else:
        raise ValueError("No Builder for %s" % name)

And the final code inside the test-cases looks like:

1
2
3
4
5
6
7
8
9

from builders import Builder

dossier = Builder("dossier") \
    .within(self.portal) \
    .titled(u"Dossier").create()
document = Builder("document") \
    .within(dossier) \
    .titled(u'Foobar') \
    .attach_file_containing("lorem ipsum").create()

Check out this gist to view our current builders.py module. Let me know what you think and leave a comment.

I'm trying to come up with more project ideas for intermediate learners, somewhat along the lines of Intermediate Python Workshop Projects.

So here's a question for people who remember coming up from beginner: as you moved from exercises like those in Learn Python the Hard Way, up to your own self-guided work on small projects, what project were you working on that made you feel independent and skilled? What program first felt like your own work rather than an exercise the teacher had assigned?

I don't want anything too large, but big enough that there's room for design, and multiple approaches, etc.

If you came to Python from another programming language, then what was the project that first made you feel competent at programming in general?

Any and all ideas welcome. Thanks in advance!

After releasing Zato 1.0, several people asked me in emails to write an explanatory material on what ESB and SOA are anyway.

I figured it would be best to add it to Zato docs directly so here it is – a no-nonsense introduction to ESB and SOA.

The concepts are so overloaded, so often misused, mistrusted and misunderstood that I feel such introductions are needed indeed.

Feel free to comment it here or there if you’d like to add something to the matter though please note that it’s an intro only and it purposefully leaves out advanced stuff, some of which is listed at the end.

You can also upvote it on DZone if you like what you’ve read. Cheers!

@zatosource

@fourthrealm

“ITERATION isn’t just for visual design. It also helps you uncover insights. A List Apart found people are often commenting and re-tweeting articles before they read them. They learned this by iterating on where the share and comment links exist on the page.”—LukeW | An Event Apart: 10 Commandments of Web Design.

ISC StormCast for Thursday, May 23rd 2013 http://isc.sans.edu/podcastdetail.html?id=3326

...(more)...

Skeu It! – and perhaps here is the reason why people went flat with their design styles. :) It’s a parody tumblr collection of some weird looking interfaces with coffee switches, jean pockets and lots of wooden clipboards. The site is now closed off, but definitely proved a point of how ridiculous (or skewed) a UI can get when pushed to the other extreme.

Credits: Justin Maxwell (@303)

I haven’t written anything on Python here in a good while.  But that doesn’t mean I haven’t been busy wrestling with it.  I’ll need to take a look at my Perforce changelists over the last months and take stock.  In the meantime, I’d like to rant a bit about a most curious peculiarity of Python […]

Volatility is a Python framework for performing memory forensics. If you haven't tried it ...(more)...

I have done some improvements in the plugins: python_console_ipython, python_autocomplete, python_utils, js_utils, xml_pretty and django_utils. These plugins I added a month and a half ago (except python_console_ipython) to the kate repository. I have done two improvements and a new feature:

• Now they work with Python2 and Python3 (except python_autocomplete, this only works with Python2, due pysmell dependence)
• Now they have a configuration page (except python_autocomplete, this should not have configuration parameters)

Page Config Plugins

The new feature is the integration of the python_autocomplete and python_console_ipython plugins with the project plugin. The behaviour of these plugins depends of the loaded project. That is to say, the python_autocomplete plugin autocompletes with our project modules. Currently the kate community is working to add a new python autocomplete  using jedi (this will work with Python2 and Python3).

Python Autocomplete (with our modules)

And the python_console_ipython plugin has something that we can name the project console. A ipython shell with the python path of our project and with the environments variables that the project plugin needs.

IPython Console (converted in a django shell)

To use this we need to add in the project file (.kateproject) a new attribute named “python”, with this structure:

 {
  "name": "MyProject",
  "files": [ { "git": 1 } ],
  "python": {
        "extraPath": ["/python/path/1",
                      "/python/path/2",
                      "/python/path/n"
        ],
        "environs": {"key": "value"},
        "version": "3.2"
    }
 }

I am a django developer, as we say in Django we can come to have a django shell (python manage.py shell) integrated in our editor. But this feature is a generic feature not tied to Django. This feature can be used by other Python developers. I have added only a specific feature to the django developers. If we set in the project file (.kateproject) the attribute projectType with the value Django, the ipython shell automatically loads the models and the settings like a shell_plus does.

  {
   "name": "MyProject",
   "files": [ { "hg": 1 } ],
   "python": {
        "extraPath": ["/python/path/1",
                      "/python/path/2",
                      "/python/path/n"
        ],
        "environs": {"DJANGO_SETTINGS_MODULE": "myproject.settings"},
        "version": "2.7.3",
        "projectType": "django"
    }
  }

I hope you like it

...(more)...

...(more)...

...(more)...

...(more)...

In my day job I spend about 90% of my time on the red team, performing vulnerability assessmen ...(more)...

or Complete coverage testing or More is Better testing Update 5/22/13: I’ve received several criticisms of this post. Most of them constructive. :) I’d like to take some time to re-read the post, re-read the feedback, and compose a more coherent statement about my thoughts on the matter. I agree with some points of my [...]

The post How not to test, part 1 appeared first on Python Testing.

Two days, two conferences. The first was a local, business oriented one, Kasvu Open Forum. The second, Djangocon Finland 2012, focused mainly on technology. I gave two talks in the latter one. It was very nice to experience both events and meet some new people and a few old acquaintances.

Kasvu Open Forum

Djangocon Finland 2012

Conclusion

In his presentation at An Event Apart in San Diego 2013 Scott Jehl outlined a number of ways to build responsive Web sites that take performance in account. Here's my notes from his talk: Responsive and Responsible.

• We need to build Web products to be universally accessible. This includes a lot more than just people with disabilities – it includes slow network connections, less capable devices, and more.
• Defensive design and progressive enhancement are a safety net against Murphy's Law. We can't think and code in absolutes.
• Responsive design is just part of building a responsible design. We need to consider a number of factors beyond the layout: performance, behavior, accessibility, and costs.
• Most of poor performance is our fault: the average page in 2013 weighs 1.4MB. The average load time of a top 2000 site is 6 to 10 seconds.
• Good performance is good design. Fast loading Websites make people happy.
• Webpagetest.org and Web Inspectors in the browser provide a way for you to measure performance and see what's slowing pages down.
• 86% of responsive designs send the same assets to all devices.

Content Parity, Optimized Experience

• We want to deliver content based on our user’s needs. Only a few years ago we were locked into normalizing things across a number of browsers. Today the diversity of devices makes this idea seem ridiculous. Instead we want to optimize for different devices.
• Content parity does not mean every experience is identical. Every browser that comes to our Web site is unique. We need to code in a way that doesn’t presume too much about: viewport size, orientation, font size, settings, preferences, and input modes.
• Being responsive from a layout perspective doesn’t preclude being responsive form a performance perspective.
• Using em-based breakpoints in your media queries means you are not dependent on device sizes and allow users to adjust font size without breaking layout.

Delivering Content

• To load content from a Website, a client makes a request, DNS sends it to the right host, and the host replies with the requested assets. The DNS server finds the right IP address to serve, then goes to a host to get content.
• On mobile devices, we go to a cell tower first, then to a DNS, then a host to get content. The connection to the tower takes two seconds and is totally out of our hands. That delay is unique to mobile and only happens once. Then we can send files back and forth after the initial connection is made.
• From there we load HTML and any referenced files when all blocking files (that impact rendering) have been received. Be careful of what you include in blocking requests.
• After 8 seconds, the carrier will cut off a connection so we want to load as much as possible when that initial connection is open.
• Every http request we make is a bit of a gamble -it can fail. So we don’t want to gamble too much with many requests -especially if they are blocking.

Delivering HTML

• Tiered delivery: if a piece of content is already accessible somewhere else (through a link on the page), you might consider loading it lazily.
• For example: home pages are navigation tools. They mostly include links to other parts of the site.These kinds of pages are prime for deferred loading.
• In the initial load, we could just include the critical links in the source then use Javascript to load additional content (like samples of what’s behind that link) after the initial page downloads.
• We can enhance the content itself using a technique called Ajax-include. We start with a simple URL and add a data attribute that references an HTML fragment to the link’s mark-up. When Javascript is executed, the link will be replaced with a full set of content using Ajax.
• To do this, consider using a data attribute on a link like “data-after”.
• You could take this deferred loading further and only show the additional content if a certain media query condition is met.

Delivering CSS

• CSS is a blocking element: browsers wait until it is all loaded before displaying a page. This prevents un-styled content from showing up.
• Mobile-first media queries: start with CSS that is wide open. Assume no media queries are present. Then adjust using min-width media queries.
• Mobile-first media queries deliver a broadly usable default. These initial styles go to all browsers but it sometimes you might want to use a "@media only all" qualifier to target all browsers that support media queries. This is a good way to qualify more advanced styles.
• Start with simple design and typography in the basic experience, then enhance upward.
• Enhancement qualifiers broaden access and help to simplify QA processes.
• But with this approach, we are sending all our CSS files to all browsers even if they’ll never use them.
• Every browser downloads every CSS asset today –whether it needs it or not. While we want style sheets to be there when we need them, we don’t necessarily want them to be blocking page rendering.
• Webkit does a little better, it loads media queries that apply and renders those on screen and does not block on CSS that is not currently applicable. However it still downloads all CSS files regardless of whether they can be used on the device or not.
• The best approach for CSS is still to combine all your CSS in one file. But minify and gzip it. CSS compresses well. GZIP finds repeating segments and reduces CSS file size substantially.

Delivering Images

• Images are 66% of file size on Web pages.
• Images don’t block page rendering but they can negatively impact page size and data plans.
• Background images can be managed with media query cascades to only be loaded when needed. Foreground images are another story.
• Compressive images: the quality of a jpg influences its files size more than its pixel dimensions.
• Scaling an image doesn't solve all the use cases you might want. Like the art-direction use case.
• Responsive images: two proposals have made their way into the standards process: picture and srcset.
• The picture element works like the video element in HTML. It has a number of media query-qualified images to load based on what each browser can support and a standard image for fallback when none of those attributes are true.
• Srcset is an attribute that you add to an image element. Its very good at managing pixel densities through attributes like 2x, 3x. The browser has the last say on which image to load.
• Picturefill is a Javascript polyfill that brings similar support to a DIV-based solution. This prevents pre-fetching images that are not needed.
• Should we load retina images for devices that can use them or should we give people a choice of what kind of image they want? After all, serving retina images by default really increases download size.
• The picturefill solution can be used to load a standard definition image by default and then give people the option to load a high-resolution image if they choose on their retina device.
• Managing images for all the different resolutions is getting harder and harder. Instead of using raster images for icons and background, we could use vector art using SVG.
• SVG is text it compresses very well because it is just mark-up. Referencing SVG inline is relatively easy. Browsers that support SVG load it easily but those that don’t can be supported with an onerror attribute to load a fallback image.
• You can also specify images as background images or as data URLs that don't require an additional http request.
• Grunticon is a tool that listens to a directory of SVG files, updates a CSS file that encodes all those files as data URIs as CSS classes, which can then be concatenated with other CSS files.

Delivering Javascript

• Javascript is the second largest part of our pages and it blocks page rendering until loaded.
• Start by loading the smallest amount of Javascript you can. Use it to determine what to load next. Initial Javascript: load feature tests, essential polyfills, asset loader, and a script loader.
• Yepnope is a very lightweight loader that allows you to determine when to serve Javascript.
• If a device is qualified, you can add the Javascript you’ll need everywhere and specific files based on what each device can use. How to determine what Javascript to load: broad qualification, browser features, device/environmental conditions, or template types.
• You can load some CSS with Javascript as long as it is not required for default presentation. Additional fonts or background images are good candidates for Javascript loaded CSS.
• Third party widgets (to embed on your site) should be loaded asynchronously. But support for async is not perfect as it is only supported in Internet Explorer 10+
• Surefire DOM element insertion by Paul Irish is a great article about loading Javascript effectively.
• Defend the critical path to loading key content for your pages.
• We have the tools to create rich experience without excluding people. But we need to work responsibly to do so.

In his presentation at An Event Apart in San Diego 2013 Jeffrey Zeldman walked through today's web design principles and how they can make our sites better. Here's my notes from his talk: Ten Commandments of Modern Web Design.

Thou Shall Entertain.

• We spend lots of time thinking about efficiency and usability but we also need to think about being delightful and entertaining people.
• Set a conversational tone with your body copy.
• Headlines and visuals play together. Consider how images can add life and clarity to your content pages.
• Stock photos might not be the best answer, illustrations and icons naturally come with a unique personality. Stock photos often do not. Part of being entertaining is being different.
• Error pages are an opportunity to insert personality. Try to be entertaining but be mindful of people’s mindset when an error occurs. Fun is not appropriate everywhere.

Test Everything

• People are using your Web sites on lots of different devices, you need to test on these devices. There is no substitute for using real devices to test. But getting lots of devices can be expensive -so do it strategically. You don't need every device but you need to have representative devices.
• Remote Preview is a tool that allows you to preview any URL on large number of mobile devices simultaneously. It's a tiny Javascript-based tool.
• Don’t just test your designs and sites, also test your assumptions.
• A List Apart made many decisions when redesigning. Then had lots of conversations with readers about what they chose to do. ALA didn’t include an ALT tag on author bios because they felt it was the best decision for accessibility. This goes against convention but it’s important to keep trying different things.
• Test your assumptions by publishing your intent and ideas. Encourage discussion about them. Even question the fact that you test assumptions -inception!

Thou Shall Iterate

• Iteration is how design happens: “I move stuff around on the page until it looks right” -Milton Glaser. A great designer is the one who keeps moving stuff, even when everyone else leaves the room.
• Iteration isn’t just for visual design. It also helps you uncover insights.
• A List Apart found people are often commenting and re-tweeting articles before they read them. They learned this by iterating on where the share and comment links exist on the page.

Thou Shalt Ship

• Good is the enemy of great. Great is the enemy of shipping.
• Not shipping can be soul-crushing. You need to get your designs and ideas into the world. It doesn't matter how good your product is if you don't get it out there.
• We're never really done. When you work on the Web, its a process of constant improvement.
• Consultants, raise you rates when clients don’t ship. This encourages clients to get the work you do together out and into people’s hands.

Engage Thy Community

• The most important asset you have are the people who love and use what you do. Engage with them and treat them well.
• Instagram lost a lot of public support when they changed their terms of service without explaining what they were doing and why to the community. Its most passionate users were upset about these changes and caused a big uproar.
• Fonts.com added a custom header to their homepage that highlighted the type work of designers.
• Big companies care about customers too but they often are less connected to their users than small companies.

Thou Shalt Prioritize

• Make sure you are focusing on the most important things at any given time.
• Force yourself to make decisions -not everything can be a priority.
• If you try to make things without prioritizing, you won’t ship.
• Kevin Hoffman has written a series of articles about effective kickoff meetings that highlight the importance of prioritizing work.

Additional Commandments

• Love thy user as thyself: treat people well. Do things that you would like to have done to you.
• Remember Content & Hold it Holy. Design from the content out instead of based on device breakpoints. Decide where your content requires a change and adapt layout there.
• Make sure the content people come to read is free of distractions and front and center. Let people focus on the content.
• Make magic, not perfection. Instagram’s success is likely based on how easy they made it to share photos. Many other parts of their experience were incomplete but it didn’t matter. They nailed the workflow of the most critical part of their service.
• Thou shalt prioritize: we need to work with decision makers to make sure we are working on the right things.
• Github issues, or similar software, can help you set priorities for the changes and features you want to make.
• Be true to yourself and your Websites.

...(more)...

Great design is a product of care and attention applied to areas that matter, resulting in a useful, understandable, and hopefully beautiful user interface. But don’t be fooled into thinking that design is left only for designers.

There is a lot of design in code, and I don’t mean code that builds the user interface—I mean the design of code.

Well-designed code is much easier to maintain, optimize, and extend, making for more efficient developers. That means more focus and energy can be spent on building great things, which makes everyone happy—users, developers, and stakeholders.

There are three high-level, language-agnostic aspects to code design that are particularly important.

1. System architecture—The basic layout of the codebase. Rules that govern how various components, such as models, views, and controllers, interact with each other.
2. Maintainability—How well can the code be improved and extended?
3. Reusability—How reusable are the application’s components? How easily can each implementation of a component be customized?

In looser languages, specifically JavaScript, it takes a bit of discipline to write well-designed code. The JavaScript environment is so forgiving that it’s easy to throw bits and pieces everywhere and still have things work. Establishing system architecture early (and sticking to it!) provides constraints to your codebase, ensuring consistency throughout.

One approach I’m fond of consists of a tried-and-true software design pattern, the module pattern, whose extensible structure lends itself to a solid system architecture and a maintainable codebase. I like building modules within a jQuery plugin, which makes for beautiful reusability, provides robust options, and exposes a well-crafted API.

Below, I’ll walk through how to craft your code into well-organized components that can be reused in projects to come.

The module pattern

There are a lot of design patterns out there, and equally as many resources on them. Addy Osmani wrote an amazing (free!) book on design patterns in JavaScript, which I highly recommend to developers of all levels.

The module pattern is a simple structural foundation that can help keep your code clean and organized. A “module” is just a standard object literal containing methods and properties, and that simplicity is the best thing about this pattern: even someone unfamiliar with traditional software design patterns would be able to look at the code and instantly understand how it works.

In applications that use this pattern, each component gets its own distinct module. For example, to build autocomplete functionality, you’d create a module for the textfield and a module for the results list. These two modules would work together, but the textfield code wouldn’t touch the results list code, and vice versa.

That decoupling of components is why the module pattern is great for building solid system architecture. Relationships within the application are well-defined; anything related to the textfield is managed by the textfield module, not strewn throughout the codebase—resulting in clear code.

Another benefit of module-based organization is that it is inherently maintainable. Modules can be improved and optimized independently without affecting any other part of the application.

I used the module pattern for the basic structure of jPanelMenu, the jQuery plugin I built for off-canvas menu systems. I’ll use that as an example to illustrate the process of building a module.

Building a module

To begin, I define three methods and a property that are used to manage the interactions of the menu system.

var jpm = {
    animated: true,
    openMenu: function( ) {
        …
        this.setMenuStyle( );
    },
    closeMenu: function( ) {
        …
        this.setMenuStyle( );
    },
    setMenuStyle: function( ) { … }
};

The idea is to break down code into the smallest, most reusable bits possible. I could have written just one toggleMenu( ) method, but creating distinct openMenu( ) and closeMenu( ) methods provides more control and reusability within the module.

Notice that calls to module methods and properties from within the module itself (such as the calls to setMenuStyle( )) are prefixed with the this keyword—that’s how modules access their own members.

That’s the basic structure of a module. You can continue to add methods and properties as needed, but it doesn’t get any more complex than that. After the structural foundations are in place, the reusability layer—options and an exposed API—can be built on top.

jQuery plugins

The third aspect of well-designed code is probably the most crucial: reusability. This section comes with a caveat. While there are obviously ways to build and implement reusable components in raw JavaScript (we’re about 90 percent of the way there with our module above), I prefer to build jQuery plugins for more complex things, for a few reasons.

Most importantly, it’s a form of unobtrusive communication. If you used jQuery to build a component, you should make that obvious to those implementing it. Building the component as a jQuery plugin is a great way to say that jQuery is required.

In addition, the implementation code will be consistent with the rest of the jQuery-based project code. That’s good for aesthetic reasons, but it also means (to an extent) that developers can predict how to interact with the plugin without too much research. Just one more way to build a better developer interface.

Before you begin building a jQuery plugin, ensure that the plugin does not conflict with other JavaScript libraries using the $ notation. That’s a lot simpler than it sounds—just wrap your plugin code like so:

(function($) {
    // jQuery plugin code here
})(jQuery);

Next, we set up our plugin and drop our previously built module code inside. A plugin is just a method defined on the jQuery ($) object.

(function($) {
    $.jPanelMenu = function( ) {
        var jpm = {
            animated: true,
            openMenu: function( ) {
                …
                this.setMenuStyle( );
            },
            closeMenu: function( ) {
                …
                this.setMenuStyle( );
            },
            setMenuStyle: function( ) { … }
        };
    };
})(jQuery);

All it takes to use the plugin is a call to the function you just created.

var jpm = $.jPanelMenu( );

Options

Options are essential to any truly reusable plugin because they allow for customizations to each implementation. Every project brings with it a slew of design styles, interaction types, and content structures. Customizable options help ensure that you can adapt the plugin to fit within those project constraints.

It’s best practice to provide good default values for your options. The easiest way to do that is to use jQuery’s $.extend( ) method, which accepts (at least) two arguments.

As the first argument of $.extend( ), define an object with all available options and their default values. As the second argument, pass through the passed-in options. This will merge the two objects, overriding the defaults with any passed-in options.

(function($) {
    $.jPanelMenu = function(options) {
        var jpm = {
            options: $.extend({
                'animated': true,
                'duration': 500,
                'direction': 'left'
            }, options),
            openMenu: function( ) {
                …
                this.setMenuStyle( );
            },
            closeMenu: function( ) {
                …
                this.setMenuStyle( );
            },
            setMenuStyle: function( ) { … }
        };
    };
})(jQuery);

Beyond providing good defaults, options become almost self-documenting—someone can look at the code and see all of the available options immediately.

Expose as many options as is feasible. The customization will help in future implementations, and flexibility never hurts.

API

Options are terrific ways to customize how a plugin works. An API, on the other hand, enables extensions to the plugin’s functionality by exposing methods and properties for the implementation code to take advantage of.

While it’s great to expose as much as possible through an API, the outside world shouldn’t have access to all internal methods and properties. Ideally, you should expose only the elements that will be used.

In our example, the exposed API should include calls to open and close the menu, but nothing else. The internal setMenuStyle( ) method runs when the menu opens and closes, but the public doesn’t need access to it.

To expose an API, return an object with any desired methods and properties at the end of the plugin code. You can even map returned methods and properties to those within the module code—this is where the beautiful organization of the module pattern really shines.

(function($) {
    $.jPanelMenu = function(options) {
        var jpm = {
            options: $.extend({
                'animated': true,
                'duration': 500,
                'direction': 'left'
            }, options),
            openMenu: function( ) {
                …
                this.setMenuStyle( );
            },
            closeMenu: function( ) {
                …
                this.setMenuStyle( );
            },
            setMenuStyle: function( ) { … }
        };

        return {
            open: jpm.openMenu,
            close: jpm.closeMenu,
            someComplexMethod: function( ) { … }
        };
    };
})(jQuery);

API methods and properties will be available through the object returned from the plugin initialization.

var jpm = $.jPanelMenu({
    duration: 1000,
    …
});
jpm.open( );

Polishing developer interfaces

With just a few simple constructs and guidelines, we’ve built ourselves a reusable, extensible plugin that will help make our lives easier. Like any part of what we do, experiment with this structure to see if it works for you, your team, and your workflow.

Whenever I find myself building something with a potential for reuse, I break it out into a module-based jQuery plugin. The best part about this approach is that it forces you to use—and test—the code you write. By using something as you build it, you’ll quickly identify strengths, discover shortcomings, and plan changes.

This process leads to battle-tested code ready for open-source contributions, or to be sold and distributed. I’ve released my (mostly) polished plugins as open-source projects on GitHub.

Even if you aren’t building something to be released in the wild, it’s still important to think about the design of your code. Your future self will thank you.

We’ve all been there: that bit of JavaScript functionality that started out as just a handful of lines grows to a dozen, then two dozen, then more. Along the way, a function picks up a few more arguments; a conditional picks up a few more conditions. And then one day, the bug report comes in: something’s broken, and it’s up to us to untangle the mess.

As we ask our client-side code to take on more and more responsibilities—indeed, whole applications are living largely in the browser these days—two things are becoming clear. One, we can’t just point and click our way through testing that things are working as we expect; automated tests are key to having confidence in our code. Two, we’re probably going to have to change how we write our code in order to make it possible to write tests.

Really, we need to change how we code? Yes—because even if we know that automated tests are a good thing, most of us are probably only able to write integration tests right now. Integration tests are valuable because they focus on how the pieces of an application work together, but what they don’t do is tell us whether individual units of functionality are behaving as expected.

That’s where unit testing comes in. And we’ll have a very hard time writing unit tests until we start writing testable JavaScript.

Unit vs. integration: what’s the difference?

Writing integration tests is usually fairly straightforward: we simply write code that describes how a user interacts with our app, and what the user should expect to see as she does. Selenium is a popular tool for automating browsers. Capybara for Ruby makes it easy to talk to Selenium, and there are plenty of tools for other languages, too.

Here’s an integration test for a portion of a search app:

def test_search
  fill_in('q', :with => 'cat')
  find('.btn').click
  assert( find('#results li').has_content?('cat'), 'Search results are shown' )
  assert( page.has_no_selector?('#results li.no-results'), 'No results is not shown' )
end

Whereas an integration test is interested in a user’s interaction with an app, a unit test is narrowly focused on a small piece of code:

Apps that are written in a traditional procedural style can be very difficult to unit test—and difficult to maintain, debug, and extend, too. But if we write our code with our future unit testing needs in mind, we will not only find that writing the tests becomes more straightforward than we might have expected, but also that we’ll simply write better code, too.

To see what I’m talking about, let’s take a look at a simple search app:

When a user enters a search term, the app sends an XHR to the server for the corresponding data. When the server responds with the data, formatted as JSON, the app takes that data and displays it on the page, using client-side templating. A user can click on a search result to indicate that he “likes” it; when this happens, the name of the person he liked is added to the “Liked” list on the right-hand side.

A “traditional” JavaScript implementation of this app might look like this:

var tmplCache = {};

function loadTemplate (name) {
  if (!tmplCache[name]) {
    tmplCache[name] = $.get('/templates/' + name);
  }
  return tmplCache[name];
}

$(function () {

  var resultsList = $('#results');
  var liked = $('#liked');
  var pending = false;

  $('#searchForm').on('submit', function (e) {
    e.preventDefault();

    if (pending) { return; }

    var form = $(this);
    var query = $.trim( form.find('input[name="q"]').val() );

    if (!query) { return; }

    pending = true;

    $.ajax('/data/search.json', {
      data : { q: query },
      dataType : 'json',
      success : function (data) {
        loadTemplate('people-detailed.tmpl').then(function (t) {
          var tmpl = _.template(t);
          resultsList.html( tmpl({ people : data.results }) );
          pending = false;
        });
      }
    });

    $('<li>', {
      'class' : 'pending',
      html : 'Searching &hellip;'
    }).appendTo( resultsList.empty() );
  });

  resultsList.on('click', '.like', function (e) {
    e.preventDefault();
    var name = $(this).closest('li').find('h2').text();
    liked.find('.no-results').remove();
    $('<li>', { text: name }).appendTo(liked);
  });

});

My friend Adam Sontag calls this Choose Your Own Adventure code—on any given line, we might be dealing with presentation, or data, or user interaction, or application state. Who knows! It’s easy enough to write integration tests for this kind of code, but it’s hard to test individual units of functionality.

What makes it hard? Four things:

• A general lack of structure; almost everything happens in a $(document).ready() callback, and then in anonymous functions that can’t be tested because they aren’t exposed.
• Complex functions; if a function is more than 10 lines, like the submit handler, it’s highly likely that it’s doing too much.
• Hidden or shared state; for example, since pending is in a closure, there’s no way to test whether the pending state is set correctly.
• Tight coupling; for example, a $.ajax success handler shouldn’t need direct access to the DOM.

Organizing our code

The first step toward solving this is to take a less tangled approach to our code, breaking it up into a few different areas of responsibility:

• Presentation and interaction
• Data management and persistence
• Overall application state
• Setup and glue code to make the pieces work together

In the “traditional” implementation shown above, these four categories are intermingled—on one line we’re dealing with presentation, and two lines later we might be communicating with the server.

While we can absolutely write integration tests for this code—and we should!—writing unit tests for it is pretty difficult. In our functional tests, we can make assertions such as “when a user searches for something, she should see the appropriate results,” but we can’t get much more specific. If something goes wrong, we’ll have to track down exactly where it went wrong, and our functional tests won’t help much with that.

If we rethink how we write our code, though, we can write unit tests that will give us better insight into where things went wrong, and also help us end up with code that’s easier to reuse, maintain, and extend.

Our new code will follow a few guiding principles:

• Represent each distinct piece of behavior as a separate object that falls into one of the four areas of responsibility and doesn’t need to know about other objects. This will help us avoid creating tangled code.
• Support configurability, rather than hard-coding things. This will prevent us from replicating our entire HTML environment in order to write our tests.
• Keep our objects’ methods simple and brief. This will help us keep our tests simple and our code easy to read.
• Use constructor functions to create instances of objects. This will make it possible to create “clean” copies of each piece of code for the sake of testing.

To start with, we need to figure out how we’ll break our application into different pieces. We’ll have three pieces dedicated to presentation and interaction: the Search Form, the Search Results, and the Likes Box.

We’ll also have a piece dedicated to fetching data from the server and a piece dedicated to gluing everything together.

Let’s start by looking at one of the simplest pieces of our application: the Likes Box. In the original version of the app, this code was responsible for updating the Likes Box:

var liked = $('#liked');

var resultsList = $('#results');



// ...



resultsList.on('click', '.like', function (e) {
  e.preventDefault();

  var name = $(this).closest('li').find('h2').text();

  liked.find( '.no-results' ).remove();

  $('<li>', { text: name }).appendTo(liked);

});

The Search Results piece is completely intertwined with the Likes Box piece and needs to know a lot about its markup. A much better and more testable approach would be to create a Likes Box object that’s responsible for manipulating the DOM related to the Likes Box:

var Likes = function (el) {
  this.el = $(el);
  return this;
};

Likes.prototype.add = function (name) {
  this.el.find('.no-results').remove();
  $('<li>', { text: name }).appendTo(this.el);
};

This code provides a constructor function that creates a new instance of a Likes Box. The instance that’s created has an .add() method, which we can use to add new results. We can write a couple of tests to prove that it works:

var ul;

setup(function(){
  ul = $('<ul><li class="no-results"></li></ul>');
});

test('constructor', function () {
  var l = new Likes(ul);
  assert(l);
});

test('adding a name', function () {
  var l = new Likes(ul);
  l.add('Brendan Eich');

  assert.equal(ul.find('li').length, 1);
  assert.equal(ul.find('li').first().html(), 'Brendan Eich');
  assert.equal(ul.find('li.no-results').length, 0);
});

Not so hard, is it? Here we’re using Mocha as the test framework, and Chai as the assertion library. Mocha provides the test and setup functions; Chai provides assert. There are plenty of other test frameworks and assertion libraries to choose from, but for the sake of an introduction, I find these two work well. You should find the one that works best for you and your project—aside from Mocha, QUnit is popular, and Intern is a new framework that shows a lot of promise.

Our test code starts out by creating an element that we’ll use as the container for our Likes Box. Then, it runs two tests: one is a sanity check to make sure we can make a Likes Box; the other is a test to ensure that our .add() method has the desired effect. With these tests in place, we can safely refactor the code for our Likes Box, and be confident that we’ll know if we break anything.

Our new application code can now look like this:

var liked = new Likes('#liked');
var resultsList = $('#results');



// ...



resultsList.on('click', '.like', function (e) {
  e.preventDefault();

  var name = $(this).closest('li').find('h2').text();

  liked.add(name);
});

The Search Results piece is more complex than the Likes Box, but let’s take a stab at refactoring that, too. Just as we created an .add() method on the Likes Box, we also want to create methods for interacting with the Search Results. We’ll want a way to add new results, as well as a way to “broadcast” to the rest of the app when things happen within the Search Results—for example, when someone likes a result.

var SearchResults = function (el) {
  this.el = $(el);
  this.el.on( 'click', '.btn.like', _.bind(this._handleClick, this) );
};

SearchResults.prototype.setResults = function (results) {
  var templateRequest = $.get('people-detailed.tmpl');
  templateRequest.then( _.bind(this._populate, this, results) );
};

SearchResults.prototype._handleClick = function (evt) {
  var name = $(evt.target).closest('li.result').attr('data-name');
  $(document).trigger('like', [ name ]);
};

SearchResults.prototype._populate = function (results, tmpl) {
  var html = _.template(tmpl, { people: results });
  this.el.html(html);
};

Now, our old app code for managing the interaction between Search Results and the Likes Box could look like this:

var liked = new Likes('#liked');
var resultsList = new SearchResults('#results');



// ...



$(document).on('like', function (evt, name) {
  liked.add(name);
})

It’s much simpler and less entangled, because we’re using the document as a global message bus, and passing messages through it so individual components don’t need to know about each other. (Note that in a real app, we’d use something like Backbone or the RSVP library to manage events. We’re just triggering on document to keep things simple here.) We’re also hiding all the dirty work—such as finding the name of the person who was liked—inside the Search Results object, rather than having it muddy up our application code. The best part: we can now write tests to prove that our Search Results object works as we expect:

var ul;
var data = [ /* fake data here */ ];

setup(function () {
  ul = $('<ul><li class="no-results"></li></ul>');
});

test('constructor', function () {
  var sr = new SearchResults(ul);
  assert(sr);
});

test('display received results', function () {
  var sr = new SearchResults(ul);
  sr.setResults(data);

  assert.equal(ul.find('.no-results').length, 0);
  assert.equal(ul.find('li.result').length, data.length);
  assert.equal(
    ul.find('li.result').first().attr('data-name'),
    data[0].name
  );
});

test('announce likes', function() {
  var sr = new SearchResults(ul);
  var flag;
  var spy = function () {
    flag = [].slice.call(arguments);
  };

  sr.setResults(data);
  $(document).on('like', spy);

  ul.find('li').first().find('.like.btn').click();

  assert(flag, 'event handler called');
  assert.equal(flag[1], data[0].name, 'event handler receives data' );
});

The interaction with the server is another interesting piece to consider. The original code included a direct $.ajax() request, and the callback interacted directly with the DOM:

$.ajax('/data/search.json', {
  data : { q: query },
  dataType : 'json',
  success : function( data ) {
    loadTemplate('people-detailed.tmpl').then(function(t) {
      var tmpl = _.template( t );
      resultsList.html( tmpl({ people : data.results }) );
      pending = false;
    });
  }
});

Again, this is difficult to write a unit test for, because so many different things are happening in just a few lines of code. We can restructure the data portion of our application as an object of its own:

var SearchData = function () { };

SearchData.prototype.fetch = function (query) {
  var dfd;

  if (!query) {
    dfd = $.Deferred();
    dfd.resolve([]);
    return dfd.promise();
  }

  return $.ajax( '/data/search.json', {
    data : { q: query },
    dataType : 'json'
  }).pipe(function( resp ) {
    return resp.results;
  });
};

Now, we can change our code for getting the results onto the page:

var resultsList = new SearchResults('#results');

var searchData = new SearchData();

// ...

searchData.fetch(query).then(resultsList.setResults);

Again, we’ve dramatically simplified our application code, and isolated the complexity within the Search Data object, rather than having it live in our main application code. We’ve also made our search interface testable, though there are a couple caveats to bear in mind when testing code that interacts with the server.

The first is that we don’t want to actually interact with the server—to do so would be to reenter the world of integration tests, and because we’re responsible developers, we already have tests that ensure the server does the right thing, right? Instead, we want to “mock” the interaction with the server, which we can do using the Sinon library. The second caveat is that we should also test non-ideal paths, such as an empty query.

test('constructor', function () {
  var sd = new SearchData();
  assert(sd);
});

suite('fetch', function () {
  var xhr, requests;

  setup(function () {
    requests = [];
    xhr = sinon.useFakeXMLHttpRequest();
    xhr.onCreate = function (req) {
      requests.push(req);
    };
  });

  teardown(function () {
    xhr.restore();
  });

  test('fetches from correct URL', function () {
    var sd = new SearchData();
    sd.fetch('cat');

    assert.equal(requests[0].url, '/data/search.json?q=cat');
  });

  test('returns a promise', function () {
    var sd = new SearchData();
    var req = sd.fetch('cat');

    assert.isFunction(req.then);
  });

  test('no request if no query', function () {
    var sd = new SearchData();
    var req = sd.fetch();
    assert.equal(requests.length, 0);
  });

  test('return a promise even if no query', function () {
    var sd = new SearchData();
    var req = sd.fetch();

    assert.isFunction( req.then );
  });

  test('no query promise resolves with empty array', function () {
    var sd = new SearchData();
    var req = sd.fetch();
    var spy = sinon.spy();

    req.then(spy);

    assert.deepEqual(spy.args[0][0], []);
  });

  test('returns contents of results property of the response', function () {
    var sd = new SearchData();
    var req = sd.fetch('cat');
    var spy = sinon.spy();

    requests[0].respond(
      200, { 'Content-type': 'text/json' },
      JSON.stringify({ results: [ 1, 2, 3 ] })
    );

    req.then(spy);

    assert.deepEqual(spy.args[0][0], [ 1, 2, 3 ]);
  });
});

For the sake of brevity, I’ve left out the refactoring of the Search Form, and also simplified some of the other refactorings and tests, but you can see a finished version of the app here if you’re interested.

When we’re done rewriting our application using testable JavaScript patterns, we end up with something much cleaner than what we started with:

$(function() {
  var pending = false;

  var searchForm = new SearchForm('#searchForm');
  var searchResults = new SearchResults('#results');
  var likes = new Likes('#liked');
  var searchData = new SearchData();

  $(document).on('search', function (event, query) {
    if (pending) { return; }

    pending = true;

    searchData.fetch(query).then(function (results) {
      searchResults.setResults(results);
      pending = false;
    });

    searchResults.pending();
  });

  $(document).on('like', function (evt, name) {
    likes.add(name);
  });
});

Even more important than our much cleaner application code, though, is the fact that we end up with a codebase that is thoroughly tested. That means we can safely refactor it and add to it without the fear of breaking things. We can even write new tests as we find new issues, and then write the code that makes those tests pass.

Testing makes life easier in the long run

It’s easy to look at all of this and say, “Wait, you want me to write more code to do the same job?”

The thing is, there are a few inescapable facts of life about Making Things On The Internet. You will spend time designing an approach to a problem. You will test your solution, whether by clicking around in a browser, writing automated tests, or—shudder—letting your users do your testing for you in production. You will make changes to your code, and other people will use your code. Finally: there will be bugs, no matter how many tests you write.

The thing about testing is that while it might require a bit more time at the outset, it really does save time in the long run. You’ll be patting yourself on the back the first time a test you wrote catches a bug before it finds its way into production. You’ll be grateful, too, when you have a system in place that can prove that your bug fix really does fix a bug that slips through.

Additional resources

This article just scratches the surface of JavaScript testing, but if you’d like to learn more, check out:

• My presentation from the 2012 Full Frontal conference in Brighton, UK.
• Grunt, a tool that helps automate the testing process and lots of other things.
• Test-Driven JavaScript Development by Christian Johansen, the creator of the Sinon library. It is a dense but informative examination of the practice of testing JavaScript.

Zato | home page

Zato is an ESB (Enterprise Service Bus) which is written in Python. It is free and open source (LGPL).

http://en.m.wikipedia.org/wiki/Enterprise_service_bus

Tibco was one of the first ESB products and Mule is an open source one.

According to the Zato site:

It supports HTTP, JSON, SOAP, Redis, JMS WebSphere MQ, ZeroMQ, FTP, SQL.

It has a web admin GUI, a CLI and an API.

Documentation and commercial support are available.

I got to know about Zato recently from the main  developer, Dariusz Suchojad, who had earlier written to me  regarding my blog post about PyMQI:

PyMQI, Python interface to IBM WebSphereMQ (formerly IBM MQSeries):

http://jugad2.blogspot.com/2013/02/pymqi-python-interface-to-ibm.html

Dariusz was a maintainer of PyMQI and also a developer on Spring Python, which is sort of a port of the Java Spring framework to Python.

Zato docs (quite detailed):

https://zato.io/docs/index.html

Part 1 of a basic Zato tutorial:

https://zato.io/docs/tutorial/01.html

I took a look at the tutorial. Broadly, it shows how to install Zato, create a simple Zato service in Python, that talks to PostgreSQL and Redis, and deploy it. Two servers get created, behind a load-balancer, and the service gets hot-deployed to the servers. Then curl is used to access the service. (This tutorial does not create a real client; curl is used to simulate one.)

Zato looks interesting and powerful (and somewhat complex, but that is to be expected for a product like an ESB).

I will check it out more and then report on my findings.

- Vasudev Ram
dancingbison.com

Dexterity is the new content-type development system built into Plone 4.3. It's also usable with Plone 4.1 and 4.2. Lately I've been working on developing a fairly sophisticated content type with Dexterity. It has fieldsets, smart validation and real vocabularies.

All these features were developed through the web. This meant that I was able to show them to project stakeholders — and even do some light usability testing — before ever turning the project into an add-on package. And, when I did convert the project into a Python package, nothing was lost.

Want more? I'll be teaching a class on Developing with Dexterity, June 3-4 at Plone Symposium Midwest.

If you've touched Dexterity at all, you've realized that you may use the TTW field editor to rapidly create a content type with a full set of fields and behaviors. You may be surprised, though, to learn that it's possible to organize the add/edit form into fieldsets, or to wire in validation and vocabularies, without moving the content type to an add-on package.

The trick is that it's possible to edit the XML representation of the field schema all the way through the TTW development process. XML edits show up immediately in your Dexterity type's field display and you may continue to add, move, delete and edit fields there:

If you've followed Dexterity development, you know that this is not really a trick at all: Dexterity was meant to work this way. Dexterity maintains the TTW field list as an XML representation via the supermodel package, which translates back and forth between field schemas and XML. While you're developing TTW, the editable XML representation is stored in the content type's Factory Type Information.

Documentation on how to add fieldsets, validators, vocabularies and permissions via XML is available in the recently created Dexterity XML Reference. To give you a hint of how it works, it's this easy to do a fieldset:

<schema>
  ...
  <fieldset name="test"
          label="Test Fieldset"
          description="Description of test fieldset">
      <field name="three" type="zope.schema.TextLine">
        <description/>
        <title>Three</title>
      </field>
      <field name="four" type="zope.schema.TextLine">
        <description/>
        <title>Four</title>
      </field>
  </fieldset>
  ...
</schema>

The Bad News

The gotcha is that editing the XML is currently a ZMI step. Go to portal_types, find the type, edit the XML.

The Good News

This is about to get better. The next minor release of Dexterity will have an "Edit XML Model" on the field editor:

Pushing it will use Plone 4.3's new resource editor package (built on the Ace editor) to open an editor. And, not only can you edit, but on save you'll get XML syntax and Dexterity resource checking:

When you're ready to move your project to a Python package, you may keep the XML model you've developed and continue to elaborate your fieldsets by editing that model.

We're pleased to announce PyPy 2.0.2. This is a stable bugfix release over 2.0 and 2.0.1. You can download it here:

http://pypy.org/download.html

It fixes a crash in the JIT when calling external C functions (with ctypes/cffi) in a multithreaded context.

I find it sad that in times when people are facing disaster, many have died, others missing, a ...(more)...

...(more)...

p4a.plonecalendar is a calendar for Plone. Mainly it is a set of calendaring views whose main feature is that can be used without Javascript.

Version 2.1′s main feature is that it adds Plone 4.3 support.

SUPERIMPOSED CAPTION: ‘SUBURBAN LOUNGE NEAR ESHER’
Elderly couple, Mr A and Mrs B are staring through french windows at a cat that is sitting in the middle of their lawn motionless and facing away from them. A car is heard drawing up.

The last couple of tutorials have been a bit heavy, so this week’s tutorials are going to balance that out by being a little light. We’re having a look at a couple of different aspects of the Python language.

List Comprehensions
The first is comprehensions:

>>> a_list = [1,2,3,4,5]
>>> b_list= [element*2 for element in a_list]
>>> b_list
[2, 4, 6, 8, 10]

In this example, we have automatically generated a new list b_list from an existing list* a_list by using a list comprehension. The structure of the comprehension is, I hope comprehensible. If not, it is a little hard to explain in steps. The comprehension above is equivalent to:

>>> b_list = []
>>> for element in a_list:
...    b_list.append(element*2)
... 
>>> b_list
[2, 4, 6, 8, 10]

We could call the variable element anything we liked – it is just another variable:

 
>>> b_list = [baloney*2 for baloney in a_list]
>>> b_list
[2, 4, 6, 8, 10]
>>> 

You can also add conditions. Let’s say you only wanted the even elements in a_list:

 
>>> b_list = [element for element in a_list if element%2 ==0] #ie remainder is 0 when dividing by two
>>> b_list
[2, 4]
>>> 

The condition here is if element%2 ==0, but you can substitute other conditions (as long as they resolve to either True or False). You can have a comprehension which relies on multiple variables (this example is from the Python documentation):

 
>>> [(x, y) for x in [1,2,3] for y in [3,1,4] if x != y]
[(1, 3), (1, 4), (2, 3), (2, 1), (2, 4), (3, 1), (3, 4)]

Unwinding this is a little tricky – for each element in [1,2,3] it runs through each element in [3,1,4] (ie 9 comparisons in all) and appends the tuple if the elements are not equal.

List comprehensions provide an easy shorthand for constructing lists. Moreover, they are often more readable than writing out the for loops explicitly.

Tuples
The second topic is tuples.
The other thing we’re going to look at is tuples (pronounced, variously, “tupp-lls”, “two-pls” and, to some people, “tyou-pls” – my preference is tupp-lls, rhymes with couples). Tuples are a little like lists, except that they are immutable. That is, once they are made they cannot be changed. Tuples are made by putting the elements in round braces [actually, adding commas between them and, sometimes, also adding braces]:

 
>>> my_tuple = (1,2,3)
>>> my_tuple
(1, 2, 3)
>>> my_list = [1,2,3]
>>> my_list
[1, 2, 3]

Elements of the tuple are referenced in the same way as you’d reference a list but, unlike lists, these elements cannot be changed (tuples are “immutable”):

 
>>>my_tuple[0]
1               
>>>my_tuple[0]=2
Traceback (most recent call last):                                         
  File "<stdin>", line 1, in <module>                                      
TypeError: 'tuple' object does not support item assignment    

The TypeError is telling us that you can’t change the elements of a tuple. To make a tuple with a single element is a little difficult because the interpreter could just interpret the parentheses as determining order of operation (think (1+2)*3). Instead, we put a comma after the single element to indicate that we are creating a tuple:

 
>>> my_tuple = (1)  # no comma, so Python just thinks it's a number
>>> my_tuple  
1             
>>> my_tuple[0]  # just a number, so has no elements
Traceback (most recent call last):                                                                           
  File "<stdin>", line 1, in <module> 
TypeError: 'int' object has no attribute '__getitem__'
>>> my_tuple= (1,)
>>> my_tuple
(1,)                                                                                                                 
>>>my_tuple[0]                                                                                                       
1              

So, if a tuple does what a list can do, only less, why bother with a tuple? Why not use a list? Well, tuples are easier for the Python interpreter to deal with and therefore might end up being faster. Tuples might also indicate that you have an ordered list where the ordering has some meaning (for example, a date tuple might store year, month and day (in that order) in tuple). The fact that you’re using a tuple then flags that each of the entries has a distinct meaning or use and that their order is significant. Another pragmatic reason to use a tuple is when you have data which you know shouldn’t change (like a constant). So, if you accidentally try to change one of the tuple’s entries, you will have an error thrown.

Finally, since tuples are immutable they can be used as keys in dictionaries, unlike lists:

 
>>> my_dict={}
>>> my_tuple=("A Name",23,"A location")
>>> my_list= list(my_tuple)
>>> my_dict[my_tuple]="Client 1"
>>> my_dict[my_list]="Client 2"
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: unhashable type: 'list'

Notes:
* as per Don’s comment, you can use any iterator, but we haven’t talked about them yet, so they don’t yet exist.

After a very painful porting experience with Jinja2 to Python 3 I basically left the project idling around for a while because I was too afraid of breaking Python 3 support. The approach I used was one codebase that was written in Python 2 and translated with 2to3 to Python 3 on installation. The unfortunate side-effect of that is that any change you do requires about a minute of translation which destroys all your iteration speeds. Thankfully it turns out that if you target the right versions of Python you can do much better.

Thomas Waldmann from the MoinMoin project started running Jinja2 through my python-modernize with the right parameters and ended up with a unified codebase that runs on 2.6, 2.7 and 3.3. With a bit of cleanup afterwards we were able to come up with a nice codebase that runs in all versions of Python and also looks like regular Python code for the most time.

Motivated by the results from this I went through the code a few more times and also started migrating some other code over to experiment more with unified codebases.

This is a selection of some tips and tricks I can now share in regards to accomplishing something similar.

import sys
PY2 = sys.version_info[0] == 2
if not PY2:
    text_type = str
    string_types = (str,)
    unichr = chr
else:
    text_type = unicode
    string_types = (str, unicode)
    unichr = unichr

if PY2:
    def __str__(self):
        return self.__unicode__().encode('utf-8')

if not PY3:
    def __str__(self):
        return self.__unicode__().encode('utf-8')

if PY2:
    def implements_to_string(cls):
        cls.__unicode__ = cls.__str__
        cls.__str__ = lambda x: x.__unicode__().encode('utf-8')
        return cls
else:
    implements_to_string = lambda x: x

@implements_to_string
class User(object):
    def __init__(self, username):
        self.username = username
    def __str__(self):
        return self.username

def with_metaclass(meta, *bases):
    class metaclass(meta):
        __call__ = type.__call__
        __init__ = type.__init__
        def __new__(cls, name, this_bases, d):
            if this_bases is None:
                return type.__new__(cls, name, (), d)
            return meta(name, bases, d)
    return metaclass('temporary_class', None, {})

class BaseForm(object):
    pass

class FormType(type):
    pass

class Form(with_metaclass(FormType, BaseForm)):
    pass

if PY2:
    iterkeys = lambda d: d.iterkeys()
    itervalues = lambda d: d.itervalues()
    iteritems = lambda d: d.iteritems()
else:
    iterkeys = lambda d: iter(d.keys())
    itervalues = lambda d: iter(d.values())
    iteritems = lambda d: iter(d.items())

if PY2:
    def implements_dict_iteration(cls):
        cls.iterkeys = cls.keys
        cls.itervalues = cls.values
        cls.iteritems = cls.items
        cls.keys = lambda x: list(x.iterkeys())
        cls.values = lambda x: list(x.itervalues())
        cls.items = lambda x: list(x.iteritems())
        return cls
else:
    implements_dict_iteration = lambda x: x

@implements_dict_iteration
class MyDict(object):
    ...

    def keys(self):
        for key, value in iteritems(self):
            yield key

    def values(self):
        for key, value in iteritems(self):
            yield value

    def items(self):
        ...

if PY2:
    def implements_iterator(cls):
        cls.next = cls.__next__
        del cls.__next__
        return cls
else:
    implements_iterator = lambda x: x

@implements_iterator
class UppercasingIterator(object):
    def __init__(self, iterable):
        self._iter = iter(iterable)
    def __iter__(self):
        return self
    def __next__(self):
        return next(self._iter).upper()

>>> import codecs
>>> codecs.encode(b'Hey!', 'base64_codec')
'SGV5IQ==\n'

Montréal-Python would like to invite you all to the next Python Project Night, on Thursday, the 30th of May, 2013 at the offices of Caravan.

Like on previous nights, it’s an informal meetup where people work on different projects and generally mess around with Python code. Everyone is welcome, from the grizzled python hacker to the absolute beginner who just finished their first workshop. We will encourage people to help each other and we will also have dedicated helpers to help people get started.

As per usual, beer and pizza are provided, so just bring your laptop computer.

If you have any projects you would like to work on, please post them on the mailing list: montrealpython@googlegroups.com. If you don’t have any ideas, don’t worry, we will find you a project that needs help.

When: Thursday, May 30th 2013 from 7 PM to 9:30 PM

Where: Caravan, 5334 de Gaspé, office #1204 (Montreal)

Where to sign up: Please sign up on our Eventbright event

We would like to thank for hosting our event!

Last year, I illustrated the importance of mobile by highlighting how many devices enter the World each day compared to the number of people born per day on our planet. The ratio was striking. Looking at the same figures today is even more sobering.

The End of 2011

The total of smartphones entering the World per day was about 1.45M devices compared to 371,124 births.

The End of 2012

The total of smartphones entering the World per day was about 3.6M devices again compared to the same 371 thousand births.

Hope you've got you multi-device design strategy in order.

In her presentation at An Event Apart in San Diego California 2013 Sarah Parmenter talked about the changes responsive Web design requires of Web designers. Here's my notes from her talk on Responsive Design Workflow:

• Any change is accompanied by drawbacks and discomforts. We're going through this transition right now. Responsive design is new and can be hard.
• We're used to a fixed canvas when we design but the multi-device Web is filled with many canvases of varying size and shape.
• We have to think in terms of designing a puzzle vs. designing a single fixed canvas. We need to work in terms of proportions.
• Globally, mobile will continue to grow at a rate of 66% year on year. This forces many designers to adapt. There's no turning back. We can't go back to fixed canvas designs.
• We all like order and structure in our lives that's why today feels so overwhelming for many of us.

Experience

• Experience: defining, crafting, and honing. To craft the experience, you have to think in terms of emotions: what do you want to convey and to whom?
• When your product or service gets an emotional reaction or buy-in, half the battle has been won.
• WuFoo, for example, sent hand written notes to customers thanking them for using their service.
• Digitally, we can create experiences through white space and aspirational imagery.
• There are three questions that can help you define your experience.
• What is the single reason someone is coming to my site/store/app? Make sure that experience is great.
• What is causing the most friction with my clients/users/visitors?
• What is already authentic about your product or service? What makes you unique?
• How do you want people to feel when they use your product or service? Accomplishment, empowerment, not just happiness should be up for consideration.
• If you define the expectations for experience first, you'll have a way to discuss and decide other choices as you move forward.
• What causes the least amount of friction for my users and application? Likely web vs. native discussions will come up. 8 out of 10 times it comes down to budget.

Content

• How do we define content structure? Start with content hierarchy: what is most important information in your product? You can learn this through direct observations, click tracking, server logs or more.
• You can design with complete content, but not without an understanding of the content structure.
• Even if you get content in advance, it may need to be re-written or adjusted for the Web. As a quick fix, consider using a traffic light system: red (remove), yellow (for large screens only?), green (all devices).
• If you rewrite content, leave comments on why it was modified.

Aesthetics

• When did Photoshop become a dirty word? All of the sudden no one wants to talk about using Photoshop to design but not everyone can design in the browser.
• Visual design tools still have their place.
• UI pattern sites can help you explore ideas for the design of user interface elements. They catalog various solutions for common design patterns.
• 44x44px is Apple's guidelines for minimum touch target sizes. To make designs work with touch interfaces.
• Cage is a tool that allows you to get approvals from clients more easily.
• Getting sign-off on components is also possible. Especially if you treat design as a set of puzzle pieces vs. a single fixed canvas.
• A transparent layer of touch target sizes can be overlaid on a comp to make sure all the touch targets are sized appropriately.

Build

• For native applications, you need to crop UI elements to be stretchable, which maybe be different than the way you create assets for the Web.
• Creating multiple assets for different screen resolutions can be challenging. A scratch file of the UI elements in an interface can isolate all the assets you need to give developers into a single file.
• Slicy is a Photoshop supporting application that allows you to name layers or groups with asset names (png, gif, etc) and export all the required assets for a project at once. It’s great with scratch files.
• Slicy can automatically export assets when your Photoshop file changes. This can be a big time savings for designers.
• Android designs may require more assets for drawable-hdpi drawable-idpi drawable-mdpi and drawable-xhdpi formats.
• When making assets for Android, 15% of your 2x image size allows you to create android xhdpi artwork. The nine-patch re-sizer tool can then create the other assets you need.
• The iOS app icon template can help you assemble all the image assets you need for iOS icons.
• WhatFont is a tool (bookmarklet) for finding what fonts a Web site is using.
• CSS Hat is a Photoshop plug-in that shows you the CSS code you need for
• Sprite Cow is a free tool from managing CSS sprite images.
• Retina.js automatically looks for retina versions and uses those when they are available.
• When working with CSS, make sure you use the original size of an image in your code to resize it, not the original code.

There is no science to creativity. It’s about having the right people in place to make the right choices.

In his Billboards & Novels talk at An Event Apart in San Diego, CA 2013 Jon Tan talked about important considerations for font setting and selection on the Web. Here's my notes from his talk:

• The Web is reading: how can we give them a better experience doing that?
• Language is human communication through the use of written and spoke word in a structured way. Words are gestures that paint pictures in our mind.
• A recent study found that “there are important differences between good and poor typography that appear to have little effect on reading speed and comprehension.” People are really good at making sense of even bad writing.
• This same study though found that “good typography induces a good mood.” Putting people in a good helps them complete tasks and even underestimate how long the task took them. Basically, time flies when you are having fun. Good typography can help with that. That’s why as designers we should care about good type setting and selection.
• The Web is a crude medium for typographers because they have to deal with a wide range of devices: different pixel density and screen sizes.
• In addition to huge differences in the quality of screen resolutions, devices can have distinct rendering environments for type: standard smoothing, direct write, clear type, core type + core graphics, etc. This introduces variation in when fonts get anti-aliased (font size) and how they look when smoothed.
• Often fonts have to be redrawn several times to work well on many screens.
• A typeface is an idea. It will be redrawn for when/how it is used. For fonts that can mean different adjustments for print and for screens. For example, Matthew Carter’s Bell Centennial font was designed for high-speed printing in phone books where ink can bleed. Similarly, Abril and Siri fonts have variations that adjust for screen differences.
• Carter also designed Verdana and fonts optimized for the screen.

Fonts for the Screen

• Some fonts are optimized for Web. Lean towards those.
• Check that the font you want is licensed for Web site use.
• Test the smallest screen size first or on the most adverse screens where fonts are likely to have rendering issues.
• Confirm language support. If you require certain languages, make sure they are available.
• What font variants and features do you need? old style numbers, punctuation, spaces, fractions, small caps, symbols, ornaments, ligatures, etc?
• Legibility is taking delight in the smallest things. Because the small details matter.
• Letters within a word are recognized simultaneously. We skip along lines in saccades with pauses and fixations that allow use to understand groups of letters before reading on.
• It's really important that people can recognize letter forms.
• The text “agh! iIl1” is a good way to get a flavor of a font. It helps you see how legible a face is and it’s characteristics.
• Kerning and ligatures: text-rendering and optimizeLegibility can be set on Safari and Chrome to enhance font rendering.
• Hyphenation styling options are supported in new versions of FireFox, Safari, IE10, and hopefully more browsers soon.
• Open Type features are coming soon but you can begin to use them in a progressive enhancement workflow. These elements allow you to turn on/off specific open type features within fonts.
• Scan paths are how we move visually through Web pages. Hierarchy can guide people through the elements within a layout. Aim for deliberate interruptions: using position, density, space, hue, luminosity.
• Use interruptions for meaning not just artistic flair.
• The measure is how long a column should span in order to remain legible. A good average is 40 to 50 characters.
• Look for interruptions in the scan path. Squint to see what catches your attention. If everything is calling for your attention, then you can't focus on anything.
• There are no rules just good decisions. Remember there’s nuance and subtlety behind design.

Emotional Communication

• Sometime there are no words. We recognize faces in 40ms and have an emotional reaction without consciously knowing we’ve seen a face.
• Language can be insufficient to explain the things we are seeing and feeling.
• There are 4.2 million colors on an advanced display but we don’t have names for all of them.
• We communicate something emotional with the font we choose and how we set them. Language is not necessary for emotion.
• Fonts are way-finding apps for emotions. Embedded in fonts is an idea that can communicate to people and affect their mood on a visceral level.
• We are trying to get people to destinations. To create impact (short form text) or immersive experiences (log form text).
• Type shapes our experience. It paints pictures in our mind.
• “Details in typefaces are not to be seen but felt.” –Erik Spiekermann
• It's all about emotion –use it for doing the right thing with type. “Don’t think. Feel.”

In his The Map Is Not The Territory presentation at An Event Apart San Diego CA 2013, Ethan Marcotte shared his thoughts about the changing definition of the Web and his philosophy for making broadly accessible experiences. Here's my notes from his talk:

• Maps capture our understanding of a space. They make us aware of our surroundings and make things feel a little less foreign.
• Randal developed a new map for New York. 2 out of every 5 buildings in New York were “mapped over”. This system was designed for use to create regularity. His was a system that became beautiful through use. Randal’s map was attempting to define a new territory: what could a territory be or should be.
• We’ve been focused on a relatively small portion of the Web: a few desktops & laptops. We carried over existing ideas (canvas, composition, typography) about design and processes from our knowledge of print.
• Mobile reminded us that the control we had over the Web was an illusion. We’re now keenly aware people want to access our content wherever and whenever they want.
• We used a number of techniques to make react to an ever changing set of devices on the Web.
• The three main ingredients of a responsive design: fluid grid, flexible images, and media queries. This is an attempt to embrace the fluidity of the Web and design across device boundaries. This simple recipe has blossomed into lots of amazing examples.
• The movement beyond the desktop is continuing into multi-device experiences. Mobile is driving this new reality forward.
• We’re drawing a new map and marking it with new sites both responsive and device specific. But this map is far from complete.

Building A Responsive Application

• Editorially is a completely responsive application for collaborative writing.
• Fluid grid: target/context = result. Starting from a pixel based layout you can determine the percentages you need to create a flexible design.
• Every point in a design allows you to consider whether you want to make major or minor shifts in a design using media query breakpoints. This is a cascading waterfall effect. Start from a baseline small screen experience and enhance as you go wider.
• Sometimes it is helpful to step back from the page and instead focus on a system of layout components.
• Small screen interfaces force you to simplify elements like navigation menus. To do so, you may sort tasks into logical groupings. This information sort can apply to all screens.
• When you move to larger screens, you can reposition elements and even pull some elements out from a menu into the mani navigation. Absolute positioning allows you to do this.
• Try to separate priority and layout. In a baseline layout, use the HTML structure to reflect the importance and sequence of content and actions.
• Use breakpoints to protect your content.

Toward a New Map

• Many sites have been having success with responsive design. The Boston Globe and several e-commerce sites have published statistics about the positive impact responsive redesigns have had.
• The Tehan-Lax and Oakley Moto sites are very beautiful designs but very large in terms of file size from 3MB to 85MB.
• Responsive design has often been criticized for being too heavy (not performant enough). But the truth is most Websites are much to heavy for today’s reality.
• In 2009, the average size of a Web site was 320kb. Today in 2013, it is 1.4MB. In just over two years, we’ve tripled in size. Moore’s law has not kept up with bandwidth.
• More people in the world have mobile devices than access to toilets and latrines. In Africa, 60% have mobile devices (700M). That’s more than have access to clean water.
• Mobile devices are shared across multiple people in many developing nations. This is slowly changing as smartphones get cheaper.
• A number of unique mobile services in Africa are all designed for reach.
• What’s happening in these developing areas is emblematic of what’s happening across the World. A large portion of the world is coming online now, on less capable devices and networks than we are used to. Are we ready for this new reality?
• Randal developed a new map for New York. 2 out of every 5 buildings in New York were “mapped over”. This system was designed for use to create regularity. His was a system that became beautiful through use.
• Randal’s map was attempting to define a new territory: what could a territory be or should be.
• We need to move toward a sustainable model for Web design through reduction and reuse.
• When Youtube redesigned their player page to be 98KB vs. 1MB, they found the average load time went up. They had accessed markets they couldn’t reach before due to their high load times.
• By keeping sites light and accessible we can reach new audiences we may have kept out previously.
• A performance budget can help you manage the size of your pages.
• Grunticon is a tool that can take a folder of SVG images, create fallback PNGS, and write the CSS code you need to use the SVG images on your site.
• We need a new definition of beautiful for the Web: one marked by greater access.
• The BBC uses a simple test for “cutting the mustard” allows you to provide an experience to everyone without sacrificing experience for more capable devices.
• Editorially does the same thing, checking for the capability of the device to determine if it should load a dynamic editor or not. Browsers that can't load the editor, still load the content so you can read (but not edit).
• Let's accept the ebb and flow of things and the fact that we surrender control to our audiences.
• Let’s outline a new map that optimizes for each across many people no matter what part of the territory they reside in.

...(more)...

If SharePoint and Facebook had a baby, it would look a lot like Igloo (without the recessive balding or oversharing tendencies). Hosted, managed and with a major release every 90 days, Igloo is a whitelabel content platform built for today’s needs. We also have Sandwich Video.

» Matt Mullenweg on Yahoo-Tumblr

“We’re at the cusp of understanding the ultimate value of web publishing platforms, particularly ones that work cross-domain.”–Matt Mullenweg of WordPress.

A Cryptic Crossword Clue Solver ←

Saw this via Twitter.

It is a partial crossword solver, because it only helps solve a particular category of crossword clues - those in which the clue (which is usually a sentence or phrase) contains both a "definition" of the answer as well a hint of some kind that leads to the same answer. This solver tries to compute the answer using both the definition and the hint, and checks whether the results match. Ingenious.

I found it interesting because this is a somewhat difficult problem, and yet the author managed to create a solution (involving NLTK and parsing) that works in many, if not all cases.

Also, long ago, in college days, I had written another kind of partial crossword solver (in BASIC); it was much simpler, using a brute force method - what it did was help solve the kind of crossword clues in which the answer is a permutation of a substring of the characters comprising the clue sentence or phrase. The program would generate and display on the screen, all possible permutations of all possible substrings of the sentence, that were of the same length as the answer. Then you had to view those permutations and guess whether any of them was the right answer, based on the clue.

I wrote the permutation-generation code by hand, but saw recently that the Python itertools module has methods to generate permutations (as well as combinations) from sequences:

http://docs.python.org/2/library/itertools.html

http://en.m.wikipedia.org/wiki/Permutation

http://en.wikipedia.org/wiki/Crossword

- Vasudev Ram
dancingbison.com

Trend Micro published a report last week on a spear-phishing emails campaign that contain a ma ...(more)...

I put together a simple .deb package to install our DShield iptables client on Ubuntu ...(more)...

Photo by kennethreitz

During Django Con, I was asked how to use Circus to run & monitor a Python web application. The documentation has no single page step-by-step tutorial yet, so here goes... this blog post will be integrated into the documentation for the next release.

$ sudo apt-get install libzmq-dev libevent python-virtualenv

$ virtualenv /tmp/circus
$ cd /tmp/circus
$ bin/pip install circus
$ bin/pip install circus-web
$ bin/pip install chaussette

$ bin/chaussette

[circus]
stats_endpoint = tcp://127.0.0.1:5557
httpd = 1

[watcher:webapp]
cmd = bin/chaussette --fd $(circus.sockets.web)
numprocesses = 3
use_sockets = True

[socket:web]
host = 127.0.0.1
port = 9999

$ bin/circusd --daemon circus.ini

$ bin/circusctl
circusctl 0.7.1
circusd-stats: active
circushttpd: active
webapp: active
(circusctl)

(circusctl) help

Documented commands (type help <topic>):
========================================
add     get            list         numprocesses  quit     rm      start   stop
decr    globaloptions  listen       numwatchers   reload   set     stats
dstats  incr           listsockets  options       restart  signal  status

Undocumented commands:
======================
EOF  help

(circusctl) list webapp
13712,13713,13714
(circusctl) incr webapp
4
(circusctl) list webapp
13712,13713,13714,13973

$ bin/circus-top

$ bin/circusctl quit
ok

We are excited to announce that Enthought is undertaking a multi-year project to bring the strengths of NumPy to high-performance distributed computing.  The goal is to provide a more intuitive and user-friendly interface to both distributed array computing and to high-performance parallel libraries.  We will release the project as open source, providing another tool in [...]

----------- Guy Bruneau

08:09

>>> from sympy import nextprime
>>> nextprime(10**11)
100000000003L

>>> nextprime(10**11, 2)
100000000019L

>>> from sympy import prevprime
>>> prevprime(10**12)
999999999989L