Developer Blog

16
Oct

It’s a (jQuery-style) Promise

Posted by | Development | Leave a reply.

Photo credit to marissa voo

Photo credit to marissa voo

Way back when I brought up the topic of promises (particularly, jQuery Deferred), and I promised we would come back to the topic someday.

Well, that promise has finally resolved, and this is the done block. Don’t get it? Don’t worry, all shall be explained. If you do get it, and wish there were a done block in the Promise spec… well, read on.

Continue reading


22
Sep

Swift Journal: Day One

Posted by | Development | Leave a reply.

Swifts

Learning a language is sometimes confusing

I decided to jump right into Swift without doing any research into the writing done over the past month so that my opinions were not colored. My background is in the C/C++ and, lately, Objective-C of which I’ve become quite fond. I approached Swift with the hope that it would provide the same kind of  power I’ve found Obj-C/Cocoa to have, but with some modern newness brought in from other successful languages. It is too early, and the tools are too fresh, for me to draw conclusions on how useful it will be for production code other than that it does look promising.

TL;DR after the jump wherein I detail experiences with the Xcode playground and a small Swift based iPhone app.

Smooth

  • It took only about a ten minute glance over the language docs to be able to port my C code to Swift
  • Explicit control of nil behavior such as when to require non-nil objects
  • Enums are first class types along with classes and structs
  • Property system like Objective-C’s with custom getters and setters
  • Aspect oriented features on the properties, didGet and didSet handlers
  • The beauty of every callable block being a closure: global functions, nested functions, class methods and traditional lambda style closures
  • Syntax shortcuts when they make sense like leaving off get for a readonly calculated property or return for one line closures

Friction

  • Tools: the playground, compiler, all are early versions and have problems; but we know that, and that’s why we will be shipping Obj-C apps for a while
  • The syntax is a step back from the terseness of Objective-C towards the explicitness of C++ (Python users are laughing right now; and yes Obj-C names are wordy, read that as “readable”, but the syntax mostly stays out of the way)
  • No headers; wade through the implementation to find the declarations you need (somehow Swift’s type declaration file avoids this)
  • I don’t think I like the declaration style var x: Int = 4 which reads like “assign something to SomeType” to me
  • It took some fumbling to figure out how to define outlets and actions in my first Cocoa Touch app (where are these language extensions documented?)

Continue reading


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


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
626-427-7184


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