A few interesting ways I keep an eye on longer term technology trends.
Google Trends: php, coldfusion, java, .net, ruby (This one has some problems, as “java” comes up for the country too…)
Freshmeat Tags, sourceforge
Indeed (job listing aggregator)
Drill down to Java ORM frameworks (and JDBC itself)
Jason’s Presentation:
http://swfcamp-2009-shopper.googlecode.com/files/API%20design%2C%20modularization%20and%20components.pdf
Code can be obtained here: http://swfcamp-2009-shopper.googlecode.com/
Joshua Bloch, Google, Inc., USA How To Design a Good API and Why it Matters:
http://lcsd05.cs.tamu.edu/slides/keynote.pdf
Excerpt from Practical API design book by Jaroslov Tulach
http://openide.netbeans.org/tutorial/api-design.html
Great book about reusability:
Will Tracz - Confessions of a Used Program Salesman, Addison-Wesley, 1995
A few collected thoughts & notes from around the web regarding what makes a good component/service.
- Interface - all implementations share this. Should have few methods, use data objects as return values, take primitives as inputs, throw only custom exceptions, and be very, very well documented.
- Implementations - implement the logic behind the service. May provide extra features such as caching, or such things as optional collaborations.
- Data - data objects this service deals with. Should be immutable, comparable, cloneable as much as is possible. Should be serializable/XML/Persistance annotated in most languages.
- Storage - Data (or data.io) package should define storage API, and an in-memory data store. Allow other services/projects/subprojects to define database backed or other kinds of data stores.
- Cache - Data.Cache packages should define cache API? (or can this be standard per runtime?) Who should be in charge of caching? The service itself, or the user of the service?
- Use dependency injection for all services/data stores it requires. Use constructor-injection as much as possible.
- Throw errors early - in constructor if possible.
- Exceptions - custom exceptions for high level categories of erroneous behavior (try not to do one for every possible condition - classify, and wrap). Don’t re-throw exceptions from other frameworks - wrap in custom exception.
- Make behavior configurable via dep injection as much as possible. Use filters or strategies.
- Inject 1 configuration object instead of many options. Standardize on configuration API/Framework for each runtime/language.
- Standardize on logging framework/API for each runtime/language, and make sure it’s used (instead of System.out or simliar)
- Provide events/messages and/or hooks for important happenings so others can do things pre/post.
Posted
on June 19, 2008, 4:10 pm,
by jg,
under
My Work.
One of the products I’ve been working on for a number of years now is getting some visibility in a very cool way - the owner of the company is going to be exhibiting the product at the MIT EmTech conference in September this year.
The product is called Evenhere - its a platform for enabling product placement along a video time-line. The results can be presented on the web, on a set top box, or in any number of other interesting ways. See the website for more information.
A little coverage over at scripted.com: http://scripped.com/blog/2008/09/25/emtech-at-mit/
I’ve recently finished the functionality of my first native iPhone application. Here are some thoughts:
- Apple makes it easy to “do the right thing” as far as the UIKit libraries go, pretty nice, and cleaner & easier than Swing or .NET in many ways. Very humanistic.
- Unless I’m missing something, common tasks like field validation don’t seem to be built-in, that’s a hassle…
- No SOAP libraries yet either.
- Interface Builder isn’t quite there yet - many components still missing, so unless you’re doing a pretty simple UI, better code it by hand (which isn’t really that bad…)
- I’m not a huge fan of XCode - the code completion is very weak compared to eclipse, as is the display of errors/warnings - many more clicks/research needed to diagnose what’s going on.
- Managing your own memory sucks…
- Since I’m coding the UI by hand, lining things up pixel perfect is quite a hassle. I’d be nice if they had the concept of a layout manager, like Swing/AWT, laying out components in a grid is not intuative (many examples I’ve seen use UITableView and a whole mess of ugly switch statements - very inconvenient & hard to maintain.)
Read on for more about the app…
Read the rest of this entry »
I’ll be presenting development best practices in the Flex/Flash/AIR tomorrow at mn.swf camp. Check back on this post for a copy of the presentation after I’m done.
Here is my presentation.
Posted
on April 1, 2008, 8:08 pm,
by jg,
under
Programming.
So, I got interested in developing an application for the iPhone, but I don’t have a decent Mac to develop on. I found that the iPhone development is based on a subset of the Mac Cocoa framework. OSX came from NeXTStep. Cocoa is mostly NeXTStep libraries… hummm… how can I learn Objective-C/Cocoa on a PC… let me think… Read the rest of this entry »
Posted
on March 15, 2008, 8:09 pm,
by jg,
under
My Work.
This is an embeddable from a site I did the technical architecture work for that launched recently for KMBC Kansas City, and will be rolled out to many other TV station sites soon. Give it a click to view the entire experience.
Posted
on July 28, 2007, 11:23 am,
by admin,
under
Programming.
- Cool that it can work with plain JS and XML
- Fast rendering engine
- Cross platform/browser
- MediaElement events not great - may be due to the beta version.
I’m currently working on a very simple video player in SilverLight that will be controlled via JavaScript.
Posted
on March 20, 2006, 8:43 pm,
by jg,
under
Programming.
One of the most important concepts you can learn is Object Oriented programming. Once OOP is mastered, learning any object style language becomes much simpler. Common OOP languages used on the web: Java, C#, as well as scripting languages such as JavaScript, and ActionScript.
Check out this wikipedia article for a general overview of OOP and many links out to OOP theory, and even a few links about what’s BAD about OOP.