Eventual Consistency

• Getting E-Mail right with Django and SES

  Sending E-Mail is an important part of almost every web or mobile product. And while it may seem like a trivial thing to do at first, getting it right and finding the optimal setup is often not that easy. Spam filters, bounce rates and throttling are all things we must take into account, and sooner or later they WILL fail us.

  Here's a quick run-down on our current setup at Swayy. While it definitely isn't perfect, it held up pretty well so far, sending tens of thousands of emails, with a relatively high acceptance (and conversion) rate. I'll go over setting up Django with Amazon's Simple Email Service, while covering some best practices and things to avoid.

  Step #1 - setting up the Domain

  Before we dive into code, we first need to prepare our DNS records. There are basically two things that we need to do.

  The first step is to add a DNS SPF record - a TXT record that lets other mail servers know we allow email originating from SES to use our domain name in outgoing mail.

  $ dig swayy.co TXT
  
  ; <<>> DiG 9.8.3-P1 <<>> swayy.co TXT
  ...
  swayy.co.       3600    IN  TXT "v ...

  read more →

• Avoiding Common Backbone.js Pitfalls

  With the rise of HTML5 and the huge advancement in Javascript performance and APIs in modern browsers, single page applications are now more popular than ever. With that, several open source frameworks and libraries were born to help us develop these somewhat complex applications.

  Backbone.js, while being one of the more popular choices, is also one of the smallest ones (in both terms of scope and actual byte count). So while Backbone is tremendously helpful, it does leave a lot of grunt work for us, the developers, to do ourselves.

  This sometimes creates a bit of friction when getting started, as we face common problems, expecting Backbone to take care of them for us, when in reality we may leave "holes" or hidden bugs in our app. Here are some common ones, that are easily avoided, once we realize they exist.

  1. Creating memory leaks by not unbinding events

  A common pattern in Backbone.js is creating views that listen on changes in models or collections. This technique is usually intended to allow the view to automatically re-render itself when the underlying data changes. It also means that for large collections we may end up with many views (at ...

  read more →

• Backbone.js with Django 1.5

  Backbone.js and other client-side MV* frameworks are a relatively new paradigm in designing and building rich web applications. Since this transition is still ongoing, most serious server-side frameworks are just now catching up to this trend. Django included.

  This is not a critique on Django - most sites and apps are still built in the "traditional" way. Backbone and friends are not a one-size-fits-all solution. They have their respective use cases, but they do introduce a new level of complication that is simply not needed in many real world project.

  That being said, while there are lots of tools around to make the transition to single page apps smoother, a big part of Django is still about rendering templates, and the prevalent serialization format is still HTML.

  These are some lessons I've learned by experience, trying to reduce the friction between the two frameworks.

  Models != Resources

  Backbone.js has two classes for working with data: Models and Collections. Intuitively, this is reminiscent of Django's own Models and QuerySets, but this is generally not an accurate comparison. Backbone relies on RESTful APIs, in which a model is actually a RESTful resource.

  In real life, such resources are rarely easily ...

  read more →

• Better Python APIs

  Python comes with a large number of built-in functions, operators and keywords. They make working with data structures and built-in types very easy, but usually when we define our own data types (classes) we also tend to come up with our own ways to manipulate and consume our data.

  One of the nice things in python, is that we don't have to. We can use "underscore methods" to make our classes compatible with the built-in functions and operators.

  This makes our code easier to use and does a better job of hiding our nasty, complex implementation from the user. More importantly, it makes our code more intuitive. This means that in many cases our API will just do what the user expected it to do. I call this Code UX, and we should be working on constantly improving it.

  Here are a few practical examples for doing that:

  Make your code REPL friendly

  Python has an awesome REPL shell, which I use all the time to introspect code and to play around with implementations before finally adding them to my code base. I use BPython or IPython instead of the regular Python shell since they offer many niceties such ...

  read more →

• Improving Your Python Productivity

  I've been programming in python for a few years now, and I'm still often amazed by how clear and DRY well written Python code can be. There are many small tips and tricks I've learned over time, mostly by reading the code of popular open source projects, such as Django, Flask, Requests and others.

  Here are a few things I've picked up that are sometimes overlooked, but can really help with everyday work.

  1. Dictionary and Set comprehensions

  Most Python developers know and use list comprehensions. For those of you unfamiliar with the concept, a list comprehension is a shorter, more concise way of creating lists.

  >>> some_list = [1, 2, 3, 4, 5]
  >>> another_list = [ x + 1 for x in some_list ]
  >>> another_list
  [2, 3, 4, 5, 6]
  

  Since python 3.1 (and also back-ported to Python 2.7), we can now use the same idiom to create sets and dictionaries:

  >>> # Set Comprehensions
  >>> some_list = [1, 2, 3, 4, 5, 2, 5, 1, 4, 8]
  >>> even_set = { x for x in some_list if x % 2 == 0 }
  >>> even_set
  set([8, 2, 4])
  
  >>> # Dict Comprehensions
  >>> d = { x: x % 2 == 0 for x in range(1, 11) }
  >>> d
  {1: False, 2: True, 3: False ...

  read more →

• Google Chrome Tips for Web Developers

  Google Chrome comes packed with an awesome suite of tools to aid in development. They contain countless features and are an awesome asset when used properly. Here's a collection of a few tips I have gathered.

  Break on DOM changes

  Chrome lets you drop into the debugger when a DOM element is changed or removed. To do this, right click the element on the page and select Inspect Element to bring up the Elements panel.

  Highlight the DOM element you want to break on in the panel, right click it and choose Break On... and select the cases in which you would like to set a break point. It's really easy and helps a lot - Great for those "Who is moving my #!@#$@% div?!" moments.

  

  The magic of $0 (Dollar-Zero)

  Sometimes, when fiddling in the console, we want to reference a certain DOM element on the page. Instead of querying for it manually with document.querySelector or similar methods, we can simply use the Elements tab to select it.

  From the Elements tab, highlight the desired element, then open the console tab, and type in $0. It is now referencing the highlighted element and we can operate on it ...

  read more →

• Structuring Client-side JavaScript code

  JavaScript is a powerful language, but like any other tool it has its ugly parts and its good parts.

  One of its "features", is that it doesn't really enforce any particular packaging practices. Modules or namespaces are not first class citizens. This means that as developers we are pretty much free to do whatever we want, and with this great power, comes great responsibility.

  This is my set of best practices, detailing how to better organize projects, create structure and enforce design paradigms in a way that makes it easy to read and maintain. It's definitely not the only way to go, and might not fit all use cases, but I found it to be useful in real world scenarios for most of the projects I've done. That being said, I'm sure there is room for improvement, so I'd be more than happy to hear how your way is better and why I'm wrong and stupid.

  Breaking things down into files

  One of the first things I've learned, is that JavaScript makes it really easy to start off with a single file, listening to when the DOM is ready, and create a whole ...

  read more →

• 5 jQuery tips for intermediates

  jQuery is a much talked about library. The web is full of tips, guides and tutorials. Being a web developer, I've probably read dozens of them over the years, and it seems that they usually target only the far edges of the jQuery learning curve. It's either a tutorial for those using jQuery for the first time, or a deep dive into jQuery's structure for those competent (and willing) enough to really understand its internals.

  Being somewhere around the middle of that curve, I'm always looking for good resources, containing practical advise I could utilize in my day to day work with the library. This post is here to cater others that find themselves in that same boat.

  It's a collection of tips, tricks, and lessons I've picked up while working on Summer and prior projects. Some are slightly advanced, but don't go as far as discuss the implementation of the library. Just solid tips that helped me be more productive and happy when using the library.

  I have also included a link to a jsFiddle page for each tip, showing a real world example that you can mess around with, and get ...

  read more →

• 8 ways to make your single-page web app faster

  Over the last couple of years, the idiom of single-page web applications has gotten to be quite popular. This happened for several reasons, some technological, some driven by the demand for better user experience - but whatever the reason, it really changed the way web developers carry their work.

  A lot of logic has been pushed up the stack, to the client, resulting in thinner server side code. In a single-page app, the server handles mostly authentication and persistence, while the business logic itself (or at least a big chunks of it) has moved to the client, along with the presentational logic.

  This shift from backend to frontend naturally isn't always smooth. Client side code has a few different paradigms and uses a few principals less familiar to those coming from a server-side world (excluding maybe async environments such as node.js).

  This post is a collection of things I generally learned the hard way. A collection of solutions to common problems: some were easier to solve, some less obvious - but I bet a lot of people still tackle them when making this transition. As you'll see, these are not specific to any single framework, library or browser, but ...

  read more →

Page 1 / 1