Category Archives: Uncategorized

Salesforce “Hackathon” revisited


Having participated in the Salesforce “Hackathon” and watched the controversy unfold during judging and today, I want to share my opinion.

The event at Dreamforce was NOT a “hackathon” by definition, it was something new and something very different. The entries were more serious, the teams working on solutions were professional, and overall the stakes were higher in terms of raw prize money and visibility at Dreamforce. Along these lines, Salesforce deserves credit for creating a new type of event and should be given the license to make mistakes and innovate, rather than being judged as a classic “Hackathon”.

I feel that the “hackathon” should change into a longer year-long developer event to create new solutions against Salesforce/Heroku and steer clear of the short-term “hackathon” distinction. Here is my thoughts on next years event given that plan are afoot:

Dreamforce “Appathon” – A year long developer contest to create the best salesforce/heroku app, judged at Dreamforce.

  • 12 months to develop, start now.
  • Due week prior to Dreamforce.
  • NDA Developer access to new APIS.
  • Award top 25 teams a mini-booth at Dreamforce to present solutions.
  • Attendee Voting: Dreamforce attendees vote for top 10 solutions.
  • Judging: Judging panel determines top 5 and winner.

If the goal is to create new apps that integrate deeply with Salesforce/Heroku and to provide visibility to what is created then shifting towards an “Appathon” seems more appropriate.

Regardless, I am looking forward to participating again next year.

Ted :)

SalesForce $1M Hackathon: What I learned


This morning I received an email that zip.ly was rejected as a finalist in the Salesforce Hackathon, thus ending a 3 week sprint of software development. Attempting to assemble a product in 3 weeks is an act of insanity but having turned off consulting for the year, a good domain name, and the desire to work on something new; our team jumped in head first. The experience was well worth it as I found myself learning more in these 3 weeks than I learned all year. It was very rewarding and yielded some unexpected fruit in terms of skills and a foundation to build services.

Special thanks to the team at SalesForce who executed the Hackathon. It was perfect but the only thing I would change is adding a RedBull soda fountain onsite next year and forging a partnership with Mel’s dinner around the corner and keep them open all night for Hackathon attendees. As someone who has run developer events, the execution at Dreamforce was world class.

I learned a metric ton in building zip.ly and I wanted to share the list of technology and what worked great and what did not. As with all technology decisions, perspective matters and over the course of development my option shifted on several technologies in use.

Server-Side I used Python/Flask/Jinga/SQLAlchemy/Postgresql and this was by far the best decision. The server was easy to change and the mature ecosystem surrounding python is a great asset. I quickly found key libraries for handling Imaging and PDF generation in PIL, ReportLab.pdfgen, pyPdf, and xhtml2pdf. If you need to generate any type of PDF document between these 4 you can get the job done fast. The hardest element here was not generating the files themselves but working around not having a file system on Heroku. I found several key workarounds using Python’s StringIO and BytesIO that proved to be excellent solutions to avoiding reading and writing to disk.

For persisting files, I leaned on Amazon Web Services via the Python Boto library. It is a great library and makes working with AWS easy. Once you get keys and permissions set, you can control AWS like a boss with very little code. For example here is the code in boto to write a pdf to S3:

s3 = S3Connection()
s3b = s3.get_bucket( 'my_bucket' , validate=False )
key = s3b.new_key( 'path/to/file.pdf' )
key.set_contents_from_file( StringIO( pdf_data ) )

The trick with Boto is that keys are optionally pulled from environmental variables so this aligned well with Heroku.

Jinga templating was also a standout as I switched to using “extends” templating late and it saved us. I was quickly able to reuse assets from a library of markup and violently change our ui late. Looking back I would not have finished the app had we not done this. Jinga just works.

SQLAlchemy is amazing. It is easily one of the best DB/ORM abstractions I have every used. Yes I have used Hibernate, but SQLAlchemy falls into the ORM you can control and avoids the dark mysteries of schema migration hell. Rather than having things be automatic in SQLAlchemy, you have to tell it what to do. Here are a few great examples:

app.config[ 'SQLALCHEMY_DATABASE_URI' ] = os.environ[ 'DATABASE_URL' ]
db = SQLAlchemy( app )

class Draft( db.Model ):
    id = db.Column( db.Integer , primary_key=True )
    userid = db.Column( db.Integer )
    name = db.Column( db.String( 100 ) )
    text = db.Column( db.Text )
    signers = db.Column( db.Text )

#careful with these 2
db.drop_all() #drop em all
db.create_all() #generate tables from model classes

In zip.ly I did the db.drop_all() and db.create_all() as part of updating the app. It was trivial to generate schema changes or a whole new schema from our model classes. I will be using this library for years to come… A+.

About 1 week into development, the $99 entrance fee was refunded by SalesForce so I decided to spend those funds on an SSL Certificate for zip.ly. I purchased the cert from RapidSSL and learned the ins and outs of generating .CSR .KEY .PEM and applying them successfully to a domain on Heroku. With the SSL cert in place it enabled us to integrate SalesForce.com OAUTH and thus call the SalesForce REST API.

In the process of integrating SalesForce OAUTH2, I struggled with several libraries but quickly fall back to use Requests in Python. In short order I had OAUTH fully working and was able to call the SalesForce REST API for Identity and adding Contacts. The REST API at SalesForce is a real gem to work with given it’s simplicity. Once you get the AuthToken, you can call any API by setting the “Authorization:Bearer” header with the AuthToken and adding a JSON payload. This was a gem to work with and makes deeper SalesForce integration easy.

Client-side was a frustratingly bumpy road and while I had great ambitions of having a great Single Page Application, late in development things came unglued so we fell back to server-side page rendering. As part of the learning on the app, we started using AngularJS which is an amazing library when you know what you are doing. Unfortunately while integrating AngularJS with our JSON API, I started to see errors that I did not understand and worse the only choice I could make was to rip it out with the Hackathon deadline looming at 36 hours to go. We will return to AngularJS after learning far more.

The “B” word… “Bootstrap”. We picked Bootstrap early and I regret the decision. Bootstrap is brittle as you must accept things the “Bootstrap way” or you will struggle. For some projects it is great and will get you started fast but it is hard technology to integrate when you know exactly what you want. The CSS is filled with “important!” so you quickly go into “important! hell” and are covered in some sticky goo that you need solvent to remove. I will not go back to Bootstrap unless they restructure and remove the “important!” mess within the framework. Again it is great for some things but for detail work it can get hellish. I am tempted to move towards using Topcoat or Pure when we revisit UI selection.

EaselJS, I LOVE YOU! If you want to rock the canvas in an app, look no further than EaselJS. I had to rebuild the signing aspect of the app late to support multiple signatures and embedded text and had it fully working inside of 5hr session onsite at the hackathon. I am now extremely biased towards EaselJS as when pressed for time, this library was predictable and easy to get things pixel perfect. I even had time to spare on this element and decided to add layouts for device orientation to the signature panel. Canvas also pairs really well with FormData in JavaScript as I was able to snap images of the signature panel and iterate over the stored data and upload via XHR. Here is a snippet:

var formData = new FormData();
 var len = ziply.imageData.length;
 formData.append( "signature_length" , len );
 for ( var i=0 ; i<len ; i++ ){ 
 formData.append( "s_" + i , ziply.imageData[i] );
 }
 var xhr = new XMLHttpRequest();

When it was all said and done, the big discovery in writing zip.ly is the HTML/Markdown/Images to PDF developer workflow. It allowed me to manipulate the PDF generation late in development and template it for end users all while generating PDF rapidly server-side. Our team will be investing more to make zip.ly both a Heroku Add-on and a small business centric native app for document signing on the go. This feels like the right pivot to make in the wake of this 3 week development sprint but we will see what time does to that decision.

I had a great time participating in the SalesForce $1M Hackathon and I walked away having learned a ton and met some great people. I would encourage you to take a risk and build something outside your comfort zone, and see what happens. You will learn a ton and you will be surprised by the results.

Cheers,

Ted :)

RFC 6455 – Websocket


I have been exploring Websocket RFC 6455 recently and wanted to share my thoughts on this HTML5 addition to web technologies. Websocket provides an API and HTTP upgrade mechanism to take a standard HTTP request and upgrade it to a bi-directional socket connection. The standard includes a simple JavaScript API to instantiate a new socket and listen for events connect, close, message while being able to send messages programmatically.

Port 80/443 - The first barrier with any network communication is firewall traversal. Port 80(HTTP) and Port 443(HTTPS) are typically open both ways within firewalls. Although Websockets can operate on custom ports, they default operation to using port 80/443 depending on the protocol selected. The key is that HTTP has always used TCP/IP Sockets to communicate. When you make a URL GET/POST/HEAD request you make a TCP/IP socket connection to the target server and send a header. The server responds and closes the connection unless it is using HTTP1.1 which simply provides more persistant connections supporting multiple requests.

2 Way – Websockets allows the server or client to send messages at any time without requiring a request. After the initial HTTP handshake, you can send data to the server and the server can send data to the client. The key is that a request does not imply the server will respond and thus there are 2 independent channels of messages.

I tested Websocket using Play (Java) and Tornado(Python) Frameworks and found it trivial to get up and working with Websockets quickly. Both frameworks provide a simple means to defining a route to serve the Websocket handshake and provide events for events. Given the symmetry within the Websocket, both client and server are very similar in API. Here is the Websocket Class in Play and Tornado:

#Tornado Framework - Websocket Class
class EchoWebSocket( tornado.websocket.WebSocketHandler ):
  def open( self ):
    print "WebSocket opened"

  def on_message( self , message ):
    print "You said: " + message
    self.write_message( message )

  def on_close( self ):
    print "WebSocket closed"
//Play Framework - Websocket Controller
public class Application extends Controller {
  public static WebSocket<String> live() {
    return new WebSocket<String>() {
      public void onReady(final WebSocket.In<String> in, final WebSocket.Out<String> out){
        in.onMessage(new Callback<String>() {
          public void invoke(String event) {
            out.write("onmessage:" + event);
          } 
        });

        in.onClose(new Callback0() {
          public void invoke() {
            Logger.info("onclose");
          }
        });
        out.write("Connected");
      }
    }
  }
}

Compatibility – Today the Websocket API is deployed in the following browsers: IE10+, FF14+, Chrome 21+, Safari 6+, Opera 12, IOS 6+, Chrome Android 4+, and BB7+. With proper fallback to Flash Player on desktop browsers, this provides a very solid base of support.

JavaScript API – The JavaScript API is fairly simple to use. You simply create a new instance of WebSocket and pass in a ws:// or wss:// uri to the target server. Here is an sample:

socket = new WebSocket( "ws://example.com/live" );
socket.onopen = function( event ) { onOpen( event ) };
socket.onclose = function( event ) { onClose( event ) }; 
socket.onmessage = function( event ) { onMessage( event ) }; 
socket.onerror = function( event ) { onError( event ) };

There are some interesting service possibilities with Websockets allowing clients to query a services layer within a persistant socket connection. The hard part with Websockets is handling scalable server architectures where messages must traverse multiple servers between multiple clients. Although this is a very solvable problem with messaging libraries like ZeroMQ and server to server socket connections.

Try Websockets out! Here is a full Websockets server written in Tornado Framework in Python. It is a single file and should be fairly easy to run once you install the Tornado libraries into Python locally. Instructions for installation are located within the file itself.

Cheers,

Ted :)

Changes


Friday 9/28 will be my last day at Sencha and marks 20 days until the birth of my daughter. I am departing Sencha to focus on family and return to working as a consultant and entrepreneur.

I have been extremely lucky over the past 7 years to work for some amazing companies (Adobe, Barnes & Noble, Sencha) and I have learned a ton about business and large scale software development in the process. Sencha has been a great experience working inside a world class, fast growth startup at the heart of HTML5. In my short time at Sencha, we focused on enterprise, delivered major releases of every product, added 30+ people to the company, and welcomed a ton of application developers to the platform. It has been a distinct honor to work at Sencha, build a great developer relations team, and work with so many amazing developers in the community.

As an evangelist I only advocate for technologies that I believe in and my path has included Flash, Flex, Android, and Sencha. In the case of Sencha, I am giving up employment to build services using Sencha as a platform. I am not sure there is a better validation of Sencha and given the large scale use of Sencha frameworks at Adobe, SalesForce, Cisco, Concur, Morgan Stanley, and many others; I know this is a very sound decision.

Having started-up straight out of college, I have yet to see an entrepreneurial climate as good as today. With a command line, I can launch hundreds of servers, leverage a ton of revolutionary code, and work with amazing people remotely. The costs of starting-up have literally fallen an order of magnitude in the past 10 years and executing projects has never been easier. During my time at NOOK, I launched 63 apps which turned into a solid recurring revenue business. This success enabled me to leap quickly to Sencha and with upcoming family changes has evolved into my return to being a consultant and entrepreneur.

Long story short, I am an entrepreneur at heart, I love solving problems, and I love building things. This change allows me to focus on family while executing on a project that has been burning a hole in my pocket. For now… family, family, family!

Regards,

Ted :)

Which Framework? Document to Interactive to Application


Since joining Sencha, I have been constantly asked to compare Sencha’s web frameworks to others. Truth is comparing frameworks really depends on the user experience you want to deliver and the resources available to deliver that experience. There is an infinite spectrum of experiences possible between Document to Interactive to Application and there is a parallel set of frameworks, boilerplate, scripts, libraries for every type experience possible. Name a web toolset and you can place it on the Document to Interactive to Application spectrum fairly easily.

Sencha’s frameworks sit at the far right of this spectrum on the Application use case and fade in purpose towards the Interactive center. While you can use Sencha to deliver interactive pages, documents, or mobile websites, our tools are really 100% geared towards professional developers building native-like application experiences with web technology. Sencha provides an object-oriented and component-based paradigm for building web applications for desktop and mobile. Here are some features of Sencha’s frameworks to make it clear what I am talking about:

  • OOP - Inheritance, Packages, Mixins, Class loading with dependency support.
  • MVC – Integrated Model, View, Controller with route support
  • XTYPE – Declarative component composition. Create and load views easily.
  • DATA – Models, Stores, Connectors for simple typed server/service integration
  • UI – Modern UI Controls and Containers
  • Integrated – Everything is designed to work together.
  • Cross-Browser – Pixel perfect on every supported browser engine

While I would love it if everyone starting using Sencha frameworks, not every experience should use Sencha frameworks. I would strongly encourage you to learn and understand the diverse set of frameworks and options out there. I have learned a ton by trying out all the different web frameworks and understanding what types of experiences they best make. In many cases, their might be a better framework fit for the project you are building and you should explore your options. Most importantly get really specific about what type of experience you are creating:

  • Is it an application?
  • Is it interactive?
  • Is it media driven?
  • Is it a game?
  • Lots of pages without much interactivity?

Choose carefully, I keep seeing projects start with one framework only to watch the experience drive the chosen framework to its absolute limit. There is nothing worse than building on the wrong stack and having to refactor and rebuild with a framework switch. Make sure you know and understand the framework limitations and make sure the highest risk part of your experience is covered.

Now if you are building mobile or desktop applications experiences with web technology, we should chat. :)

On Tuesday 2/14, I will be presenting a webinar on Flex to Sencha which will focus on explaining the details of Sencha’s frameworks.

Cheers,

Ted :)

Thanks NOOK!


Today I resigned from B&N NOOK Apps to embark on a new journey in my career. Before I talk about the next destination, I wanted to talk openly about my time at NOOK Apps and say thanks to those who made it great.

NOOK Apps was an amazing journey and will always be a highlight of my career. The opportunity to build a marketplace for applications atop a new class of content centric device was big, complex, and a ton of fun. I joined a small team and we built out all the required elements to succeed from scratch in 5 months.  We launched NOOK Apps with 136 apps within an operating system update to NOOK Color. We went from 0 to millions of app installs per month and worked non-stop to make the platform better for all developers building applications. Over the past year we have helped thousands of app developers monetize great content on a new platform in a new market.

The best part of working on NOOK Apps was the team. I have worked with great teams before but never quite as good as the team on NOOK Apps. Every role was filled with a person with vast experience in the mobile space and together we made NOOK Apps a success.

Claudia, Simon, Tavares, Steven, Josh, Gideon, Cary, Titus, Eric, Ron…

Thanks, You made my time at NOOK great and we accomplished allot working together as a team.

As for next steps for me…  I will save that for tomorrow.

GO NOOK GO!

Thanks for all the fish!

Ted :)

Living in the Future


What if you received a copy of the Wall Street Journal dated November 12, 2015, today?

What if you knew what the future would be like 5 years from today, and better, how things would play out?

Where would you invest?

What problems would you solve?

What would you start to build?

For the past decade, developers within the Flash ecosystem have been living in the future building upon a stable consistant runtime with great tooling and advanced text/graphics/animation/vectors/video APIS for building interactive applications. As an ecosystem, Flash enabled amazing things, impossible things, fantastic things with a technology with very humble beginnings centered on vector graphics. I spent the last 12 years working with Flash professionally and evolving with the medium over that time has been an honor and highlight of my career.

A few years back browsers began innovating and that innovation is beginning to fix many of the inconsistencies and capabilities once only privy to Flash. While still in their infancy around rich media, browsers and standards based platforms will evolve along a similar path to the Flash ecosystem’s evolution over the last decade. The same problems, patterns, solution, services, tools, tips, tricks, and know-how will be required to make this standards based ecosystem as vibrant as Flash is today. The fact is that knowing Flash is far more than just knowing ActionScript or a raw Adobe tool, it is the knowledge of how to build rich interactive content. Much of our knowledge domain is not in implementation details but rather understanding the nature of interactive media, architecting a proven interactive solution, and balancing usability, design, and interactivity to create a great experience. In short, you have a massive upper hand in an emerging market called HTML5 and Adobe is shifting resources and investing there too.

Exploring OpenGLES – A break from Flash

For the past 8 months, I have been personally exploring and investing in tools and technologies that are focused on leveraging fast graphics and hardware acceleration using OpenGLES. As I work for Barnes and Noble on the NOOK Platform, I wanted to figure out how best to deliver fast graphics within native apps on NOOK with a lower end hardware profile (800Mhz 256Mb OpenGLES 1.1 & 2.0). Given that Flash/AIR does not directly support an OpenGL-like surface today on Android, I explored several alternatives that included CoronaSDK, Moai, Marmalade, but have settled on using the native Android SDK with ANDEngine. The output results on NOOK Color are 60fps regardless of the volume of graphics and textures I throw at the displaylist. Physics, fast vm, great java tooling, it is a real treat to develop interactive content this way! This exploration was hugely enlightening for me and has made me realize that even when I completely switch stacks my interactive skills I perfected with Flash are extremely relavant. Even the easing equations were a java port from Robert Penner’s work.

Truth is, things have changed but the foundational knowledge of interactive development will remain with us all long term regardless of what platform you target. Should you choose to focus on native or open web apps, you have a great advantage, once upon a time you lived in the future called Flash.

Cheers,

Ted :)

PS. Adobe please improve the performance of AIR on Android.

Perspective Matters


This past week I got very frustrated at a process at work. Initially I thought, surely this is broken. How could something this simple be architected this way. So I decided to understand and I dug deeper. After about 2 days of digging I found some dependencies that forced the very solution that I was complaining about. Had I been in the shoes of the creator, I would have been forced down the same path.

From the outside, problems can look trivial but inside, there is often far more at work.

As technologists we are ready to declare something stupid, silly, wrong at first glance and at times say, “I could do that better”. Behind any problem is a larger more hidden set of dependencies and problems. Problem is that often dependencies are invisible and the larger problems are hard to see unless you went though the hard lesson of actually building something under the same circumstance. It is easy to judge but solving real problems is often dramatically harder than it looks.

Perspective Matters.

cheers,

Ted :)

Live Wallpaper?


About 2 months ago I started to explore building apps to allow end users to decorate their NOOK Color device (desktop and lock screens) with licensed art/images. The exploration lead me to a simple idea of packaging collections of images within a Live Wallpaper and making then interactive on the desktop, yes wallpaper???

Given that NOOK Color has a majority female market demographic, I thought that decoration and customization would be a clear winner within NOOK Apps. Also given that end users tend to be a-technical, packaging as a Live Wallpaper meant simplifying adding them via Wallpaper Manager and making them easy to use. Ideally I wanted to avoid any type of “settings” within the apps and have all interactions occur on the desktop. My expectations were that I would most likely break even against licensing of images and open up the market for wallpapers on the device. Little did I know…

With licensed images in hand, Android SDK, and configured Eclipse, I went about coding up a simple interactive live wallpaper for image viewing. The codebase started very simple and I build in image automation using ANT and ImageMagick. I used Adobe Fireworks for master image manipulation and cropping and added support for opening the Wallpaper Manager via API (Android Intent) and deep linking into NOOK Shop via API (Android Intent) for cross-promotion. By the end of the weekend I had built 3 live wallpapers. Here is what they look like:

Yes, Beaches, Cupcakes, Paris! :)

I setup my nookdeveloper.com account and entered in all my banking info, and added all 3 apps for meta-data approval. Working with my wife Linda we decided to brand everything Abbey’s Wallpaper given the demographic and marketing fit. When the apps were approved I uploaded the final APKS, final icons, and screenshots and waited til the apps were approved and published. Once published to Shop we began to get some eye turning reports…

  1. June 17 – Fri – $412  - Interesting..
  2. June 18 – Sat – $722  - Almost double day 1. All right!
  3. June 19 – Sun – $746  - WOW Wait is this a mistake?

After the first weekend of sales we were break even on costs of 30 licensed images and selling the collections at $0.99 each was doing very well with end users.

June Sales:

July Sales:

August Sales:

Today total revenue sits at $19,630.43 against costs of $6800 plus 40+ hours of my time, for a profit of $12,830.

I never anticipated that on weekends I would find myself packaging Live Wallaper nor did I ever expect to see a market for wallpaper exist on NOOK. I had doubt that I would break even and the results today seem amazing to me given I work for Barnes & Noble on the NOOK Apps team. In doing research against my success, apps and games are yielding 10x results to what I have been seeing with wallpapers. The customers attached to NOOK Color have no hesitation to purchase interactive content, they are the same customers that have been purchasing content from Barnes & Noble for years and as they say… habits die hard. Given that apps tend to do far better overall, I am refocused on providing apps and games onto NOOK Apps but will continue to push in wallpapers via automation from time to time. Obviously one can dismiss this as a small success but the proof is that there is a real market of consumers attached to NOOK Color and they do not hesitate to purchase digital content. Even things as simple as wallpapers sell well provided the content is of quality. All told with about 40 hours of weekend work, it has yielded a small side business for me and my family and I have learned a ton about the market attached to NOOK.

To get started building apps for NOOK Apps… Visit NOOKDEVELOPER.COM

Cheers,

Ted :)

A-technical World!


Since joining Barnes & Noble I have been trying to better understand our core customer demographic for NOOK and the target user for mobile apps. This exploration has really changed my perspective on consumer software and what end users actually want, love, and most importantly expect. It has been an unexpected and eye opening experience yet it highlighted a truth that I seemed to know was true all along.

The world is by large majority a-technical!

When I write software I automatically bring a technical bias to problem solving, interaction, and UI. I make assumptions about my target user and this is where I fail. I assume they can install software, complete forms, gestures, can use the back button, understand the mouse, right-click, know something is draggable, know how to use a drop-down, etc… all the basics apply here. At issue is that each of these skills, reduces the overall addressable market for my app. The more I assume, the smaller my potential user base for my app. Designing apps for a-technical users really means starting fresh with a simple foundation of assumptions about the user.

I have found that there are 4 great techniques for addressing the a-technical users:

Write down your assumptions. Writing down assumptions lets you see the skills you are asking a user to perform. It provides an inventory of skills from which you can add new features without alienating users. Even the simplest of assumptions apply.

Teach - Ever notice how good games teach end users how to play progressively? Typically to broaden the market for a game, developers will have several levels that are essentially tutorials. How to shoot… How to throw a bird… How to use the camera. Great apps teach end users how to use the app progressively.

KISS – Keep It Simple Stupid - The other approach which has gotten every popular lately is to strip away features down to the core. Sometimes the best app does just one thing and does it very very well. The focus on simplicity removes user confusion and lets users take full advantage.

Prototype - Looking at UI allows you to quickly assess the complexity. It also makes implementation far easier especially with great tools like Balsamic Mockups. One trick I have found that is helpful is to ask an a-technical user to explain a UI back to me. You will be shocked at the responce you get in using even the simplest UI elements.

What gets really interesting is that most users on NOOK have no idea it is Android. They just expect an app to work when the icon is pressed. Users just want apps that are easy to use, provide value, and are fun. If you are interested in building apps for NOOK, you can sign up here: http://nookdeveloper.com

Cheers,

Ted :)