Developer Blog

29
Aug

5 Things I Wish My Clients Knew

Posted by | Development | Leave a reply.

"I Saw the Figure 5 in Gold" by Charles Demuth

“I Saw the Figure 5 in Gold” by Charles Demuth

Earlier this summer, I spent a few days onsite with a client working through hammering out requirements for an upcoming large project. One day during a lunch break, my client asked me a question that I’m surprised no one has ever asked me before:

“We want to be the best client you’ve ever had. What do you wish we knew so that can happen?”

I think that I came up with a fairly reasonable reply at the time, but I’ve been ruminating on the question all summer long. Here are the first five things on my list of what I wish all my clients understood about developing software: Continue reading


28
Aug

LGPL: A Summary for the Wary

Posted by | Development | Leave a reply.

Open-source Doctor

I recently went through some involved discussions with a client who has traditionally not used open-source software when a library package licensed under the GNU Lesser General Public License (LGPL) seemed to be the best choice for our needs. I kept a number of notes during these conversations and felt it was probably something that should be shared since, no matter how comfortable you are working with open-source licensed software, you probably work with (or for) someone who doesn’t share that comfort. How do you talk to them about using open source software, particularly as part of some product that you are releasing?

While you are reading this, keep in mind some things:

1) The primary focus is on the GNU LGPL since that was the center of our discussions. Some of the topics talked about here may not be similar for other licenses.
2) There are tons of all-inclusive articles about open-source software that cover all of the details of nearly every type of license. This isn’t one of those.
3) I AM NOT A LAWYER! Everything here is based on my limited understanding of the legal dealings and nothing here should be taken as any type of legal advice.

Continue reading


19
Aug

Upsource: New Code Review Tool

Posted by | Development | Leave a reply.

I have a special place in my heart for web apps that make coding management easier.  This week, my crush is Upsource, a new code review tool (and source code repository browser) that’s in a semi-public alpha period.

It looks to have a great interface for:

  • starting ad hoc reviews or requesting reviews
  • looping in other people to discuss or watch the review
  • linking to reviews or multi-line selections
  • adding new code revisions to an ongoing review Continue reading

15
Aug

Swift Link Dump

Posted by | Development | Leave a reply.

Apple_Swift_Logo

Apple surprised the Mac and iOS developer community at WWDC with the announcement of Swift, a new language for developing apps for OS X and iOS. With each beta release of iOS 8, Yosemite, and Xcode 6 the language has been evolving and the community has been quick to follow.

I’ve been saving links from Twitter and my RSS feeds since WWDC, here’s the best so far:

Language Basics

Swift Blogs

Technical

Frameworks

Testing

Experiments


13
Aug

dweet.io – Twitter for Social Machines

Posted by | Development | Leave a reply.

Last week I came across dweet.io which looks like a great way for simple internet connected devices to publish and share data with interested people, systems, and devices. Sharing publicly is free, and privately is just 99 cents per month, per thing. It’s Twitter for the Internet of Things.

5237486949_078d09dc89_z

You can “dweet” up to 2000 characters of data using a HAPI style web API that’s incredibly simple, and in turn get some easily readable JSON that looks something like:

The last 500 dweets from any thing are stored for up to 24 hours. If it hasn’t dweeted in 24 hours, its history is removed.

For connecting simple devices or services that need to periodically share some data, this is such a fantastic service.

Image from antjeverena


4
Aug

Factories, not Fixtures

Posted by | Development | Leave a reply.

Rosie the RiveterFor years, the most common way to provide test data for automated tests has been fixtures – hard-coded values, usually stored in text files.  For example, here’s some YAML-formatted data for a city model object:

- model: city
  fields:
    id: 1
    name: Los Angeles

In an environment like a Django app, this fixture would typically be loaded into a test database, and then accessed like: la = City.objects.get(id=1).

But fixtures and the frameworks that rely on them have several drawbacks:

Their data is brittle, especially when including references like unique IDs.  Changing or adding a property later may break tests.  This drawback also means that they are not easily modifiable, which tends to lead to duplicate fixtures with unwieldy names like los-angeles-with-an-extra-long-name.yaml.

They are typically loaded en masse by test frameworks like Django’s.  This can be slow if many unnecessary fixtures are being loaded for each unit test.  It also creates brittle sets of data.  For example, if an automated test is searching for objects with a matching city name and expects to find one instance, but later a new fixture is added that also matches, the test will fail.

Because fixtures are typically automatically loaded into a database by the test framework, it’s not particularly easy or fast to change the properties of an object for a single test case, which also tends to lead to an over-abundance of fixture files.

Factories, not fixtures

Test data factories solve these problems by making data and data loading more dynamic and programmable.  A factory is written in code, and while it can simply mimic a fixture by supplying default values for an object, factory libraries offer many other useful features.  Here’s a simple example factory:

Factory.define('city', City)
  .sequence('id')
  .attr('name', 'Los Angeles')

An instance of this factory could be created on the fly like: la = Factory.build('city').

Following the builder pattern, a factory generates data for all the attributes in its definition, constructs any necessary associated objects, and allows a test case to override these values.  Here’s a slightly more complex example:

Factory.define('city', City)
  .sequence('id')
  .attr('name', 'Los Angeles')
  // Define 'ref' as dependent on the id and name properties
  .attr('ref', ['id', 'name'], function(id, name) {
    return id + '-' + name;
  })

nyc = Factory.build('city', {name: 'NYC'})

Some typical features in factory libraries are:

  • integration with common ORMs; Factory.create(...) will typically build and save the object to a database
  • factory inheritance, allowing similar factories to share properties; e.g. Factory.define('city').extend('Olympic').attr('year', null)
  • lazy attributes; e.g. .attr('created_at', function() { return new Date(); })
  • associations to other factories

Factories across languages

Factory libraries have been springing up over the past handful of years.  Ruby’s factory_girl, which has been cloned to many other languages, was first released in 2008.  Several new ones for JavaScript and Objective-C have just appeared this year.

Here’s a list of factory libraries for a variety of common languages:

Test data for unit tests

A note of caution: a one line factory invocation may hide a great deal of complexity and database integration.  That may be fine for integration tests, but should be avoided for unit tests (see the blog post Factories breed complexity for a lengthier discussion).  Prefer to use simpler, non-persisted objects in unit tests.  Factory libraries may help here too by returning just the attributes as a hash or dictionary; e.g. factory_girl’s attributes_for method.


17
Jul

Realm – A New Mobile Database

Posted by | Development | Leave a reply.

Realm_—_a_mobile_database

A new mobile database for iOS (Android support coming soon) launched earlier this week called Realm. Given that up to this point your options were SQLite or something built on top of SQLite like Core Data or YapDatabase, it’s kind of a big deal. Continue reading


16
Jul

A Django-Style Admin Interface For Pyramid

Posted by | Development | Leave a reply.

pyramid-positive

pyramid_formalchemy provides a CRUD interface for Pyramid based on FormAlchemy. Which is to say it looks at your SQLAlchemy models and automagically generates an HTML interface to create, read, update and delete instances of those models from the database, very much like Django’s admin interface. That sounds pretty cool, doesn’t it? In this post I will demonstrate how to get it up and running and then start customizing the forms.

blogpost_formalchemy1

Continue reading


30
Jun

The Substance of Style

Posted by | Development | Leave a reply.

In my recent post on working remotely, I’m realizing that I kind of blew past something that we’ve always felt was key to making working on a series of projects for many different projects like working for Art & Logic on A&L projects, not a series of disconnected projects.

1D picture at the urging of my 14-year old daughter

One of the first things that the founders of A&L did was to sit down together and hash out a programming style guide. Over the years, that guide has evolved and grown, and it’s still the way that our developers write code. It’s easy to look at something like this as being a simple set of directives (“Use spaces not tabs! Opening braces go on a line by themselves!”), but it’s really much more than that.

Continue reading


25
Jun

Websockets for Backbone

Posted by | Development | 1 Reply.

Backbone + Websockets

Backbone’s had some of its thunder stolen lately by trendier frameworks like Meteor and Angular; for good reason, in most cases, as without the prosthetic functionality offered by the likes of Marionette, Backbone’s view handling (amongst a few other lacks and warts) is really just ‘roughed in’.

But the fact that a framework like marionette can be built on top of Backbone is a testament to Backbone’s flexibility – after all, as the name suggests, Backbone is really just the ‘skeleton’ of your app, and it’s willing to be fit into place however you need it to be.

For instance: Backbone’s default persistance method is via jQuery’s ajax – make a request to the server using one of the standard HTTP methods to persists changes to models in a collection to the server-side db. Works great, but maybe you need something faster/better/stronger/etc.

Like, say, WebSockets.

Continue reading


Art & Logic has been developing software on a work-for-hire basis since 1991. We have worked with over 900 clients in a diverse set of industries, including education, aerospace, music technology, consumer electronics, entertainment, financial services, and many more.


2 North Lake Avenue, Suite 1050
Pasadena, CA 91101
877-394-3810


Contact Us
© 1995-2014 Art & Logic, Inc. All rights reserved. All trademarks associated with the registered trademark "Art & Logic", including but not limited to "ArtLogic" and "artandlogic.com", are owned by Art & Logic, Inc. Terms of Use and Privacy Policy