Adam Hammer
#201-1975 Balsam ST| Vancouver, BC V6k 3M6 | 604.339.2620 |

The joys of video making

2015-04-24 22:04:04.525

I've been preparing the project for kickstarter and despite me having a fair bit of quality video equiptment on hand, I don't really know anything.

So I started by choosing a song and took some footage of the app's and websites. However the footage was disjointed and confusing. So I wrote a script for what I wanted to demo. I broke it up into parts, set a time limit, and got enough footage with some blank spots for talking.

I then attempted to get some video, however without additional script writing I was pretty much lost. I can ramble about my projects for some time, but it's surprisingly hard to fill in specifically 30 seconds on one topic, then 45 on another.

So I wrote more script, and while I haven't tested it in detail yet I've done some practice reads and the timings are pretty close. They'll fit, but still need some editing to flow naturally and more practice so I can read without obvious cues or helpers in front of me, practice, practice and more practice.

And during the practice I tried to find the best place to get the video. Initially I wanted it in my office, but the lighting doesn't really allow me to show my awesome computers and my face at the same time. I did some trials but I just wasn't happy with the aesthetic. I've taken a lot of photos and this wasn't what I liked. So I moved rooms, I took it to my nice table in my living room with a big pretty tree and in the backdrop and wide open windows with lots of light. This was a definite improvement, but the backlight was washing out the image, it still wasn't what I wanted.

So I flipped sides of the table, instead of the camera facing out of the house, it was facing in. This really brought a lot of light onto my face and really exposed everything nicely, but then I had to clean my house. Because all the backdrop would be a mess. However, after a tiny clean up, and some tinkering of my hue lights, I really think I've exposed things nicely and composed a good frame.

Now to just edit the script, read it another 40 times out loud, and then take proper footage. After which I edit it all together and upload the master to youtube.

Making movies is hard work, I appreciate the effort that others put into theirs.

Read More + Comments

E-Commerce Abilities

2015-03-25 13:44:49.839

I've added both Bitcoin and Stripe now, and can do invoicing and orders across both the Bitcoin Currency and CAD.

The process to get e-commerce in full was fairly big, and really required multiple things, so I thought I'd break it all down.

1. Inventory and Products

The basis of any sales is going to be Inventory and Products, without that you can't have sales. Lucky for me I only sell digital products and services at this time, so the Inventory stuff is a bit light, while the products is pretty full fledged. There is Warehouse, Products and Inventory tables, in order to track the Items, where they are and the information about the locations. It's pretty simple, but the basics are there.

Since I deal in digital products exclusively, I don't need to worry about Warehouse or Inventory, I just create things on demand, so it could use some more maturity to become a full fledged product, but for now it works for me. I've set up the ground-work to extends it into a full featured product soon.

2. Bitcoin Integrations

Bitcoin is integrated with BitcoinJ, a wonderful library for integrating bitcoin into your Java applications. In it's current integration a wallet is created for each organization. Bitcoin isn't supported as a native currency, however it is supported via a conversion mechanism @ bitcoin charts Api. The server polls Bitcoin charts every ten minutes or so, get's the updated BTC prices, and then uses it to do the conversion from CAD->BTC.  Every transaction receives a unique wallet address, and payments that are made to that address get reflected against the users Cart. The Bitcoin price quote is persisted with the order and is good for the limited lifespan of the cart.

There is a special integration for QR Codes, Bitcoin QR is simple, you just define a bitcoin:// payment URI that has the wallet address and amount, e.g. bitcoin://kdfajs43l23UIDS?amount=0.1

On android it is able to follow that URI scheme and launch the wallet application, or be read by the camera of the wallet application. This means that payment integrations on android are very simple, easier and more secure then traditional money. In fact, you can use this mechanism to accept anonymous payments online.

3. SSL Integration

I wanted real money integration so bad, but the initial design was http only. Https has overhead, not so much performance, but certificate overhead. Each domain needs a certificate, You can use Server Alternate Names and Wildcard domains to expand on it, but it still requires you to verify ownership of every domain. Additionally, I wasn't that experienced with SSL in the past, I was slow to get started, and I didn't want to put real money integration until I had a green bar.

The path I took to resolve these issues started with StartSSL. With StartSSL the domain verifications are free, you just need to use the automated system. I only needed to be verified once as a person, a process that took less then a day and cost about $60, and now I had certificates. However, going along this path didn't turn out ideal. Once of my original requirements was that I support any and all domains pointed at the server. WHile this is still true, there are limits to the Cert I can deliver. Java and Jetty have limitations that make it difficult for me to rotate through keys in the keychain, so it just chooses the first.  I had to make the trade/off acceptance that I would have to lock in a certificate and accept that SSL will only work on those domains that can be predefined (wild cards allowed however). So I decided to make everything on my main server @ * Even now you can go and view this page over SSL at

In the future I might generate a more versatile certificate that gives SSL access on not just the root domain, but on, etc. It will work as is, but you will get the unverified warnings from the incorrect signing.

For large clients that require SSL, they'll likely bring their own certs to the table, and luckily the future of Java does hold solutions to these limitations, and I might be able to even get by them nowadays with some work. Mostly it comes down to Server Name Indication (SNI) support, the ability for the client to tell the server early on the domain, so a certificate can be chosen from the store.

For now though, SSL is done and in there, it's secure and verified and I can't praise StartSSL enough. However, they have been a bit slow to generate a test-domain cert that I wish to include with the platform. I purhased, which I use for internal testing and I want others to as well. I never plan to put anything on that domain, however I do want people to have a working out of the box ssl setup for developers. Things like Payments, even in test mode, will not work over HTTP, it will lock the user out from doing those insecure things.

4. Stripe Integration

Now that I have SSL, it was time to choose a cart-provider and integrate the API. For this I chose stripe because of ease of implementation, reputation and fair rates. All in, the integration required some refactoring of the initial bitcoin payment support, and updates to the cart and such, but it was a breeze. Stripe was one of the easiest things I've put. In terms of user flow, making a Bitcoin payment is easier, but integration of the stripe API was was incredibly easy. 

I don't want to go over why I didn't choose other payment providers, in the future I may add additional providers. I avoided paypal howe due to their politics. I feel they put to much risk on small and digital startups, often putting unreasonable holds and being poor communicators about it, so I chose to actively avoid them. The rest of the players I'm overall neutral to.

In the future I might integrate Square POS as well, since that's a very convenient in-person channel.

5. Messaging Improvements

The Messaging system needed some improvements. Well, it still does, but the current incarnation lets me do somethign cool. It'll send push notifications, so the clients can stay up to date and have realtime communications with their customers. For example, if you place a order on, it'll create a cart and send me a message, and I'll be able to then respond, which will automatically create a user, notify the purchaser, and allow two way realtime communication between the purchaser and me, while having full accountability in the system about the order.

Once ready, invoices can be sent with https to the client using the Orders UID, and payments can be directly made via bitcoin or credit direct the invoice.


Overall I am happy with this iteration. I wouldn't call it release ready for the general public yet, but it's definitely becoming the full featured platform I want. I hope to bring it to the public soon.

Read More + Comments

Recent Updates

2015-03-01 01:25:24.454

Things are coming together, and I'm switching to a bug-fixing/marketting strategy. Recently some landmark features have been smoothed out, including push messaging. 

I want to establish and launch the basic brands, and then perhaps kickstarter the platform and maybe some specific ideas down the road.

To make things nice, I've passed over the CSS of everything again, fixed up any ugly assets and generally tightened up the Admin side of things. On the Android side it's pretty full featured, including push messaging and full threading and comment support. It's reached a point where it's not perfect, but it's complete enough to use and take to the next level. So that's the goal. Get it up and do a official launch, and hopefully be able to turn it into Platform or Hosting sales.

There is also other things in the pipeline, possible consumers for the platform, and I look forward to the day this has some real users.

Read More + Comments

On maintainable software

2015-01-06 15:51:21.549

We've all seen unmaintainable big software. I will not deny it's existance. However, because other people fucked up is not a reason to think it can't be done properly. In fact, lots of software uses these patterns already and they are all over the engineering world.

1) Design for modularity
Small modules > Monolithic design. To be able to swap and replace things is a high value 

2) Separation of Concerns
X does not need to know about Y. X takes care of X, and sends messages about X's state. Y can choose if they want to listen for messages, but X and Y do not directly talk. Things like a Event Bus help massively with this on, especially on the UX side of things. 

Once you let X and Y directly talk, you risk regressions in Y when you change X. if X talks to YZWAHBGR and you start changing any one of those things, you risk them all breaking. This is why decoupling and seperating concerns is important.

3) Immutability: Reduce side effects
Honestly, this is a big one. Immutability can seem awkward at first, but if you keep a clean model, and follow the paradigms, it can basically eliminate regressions and side effects. Most regressions are caused by someone poking around where they don't belong, doing things they don't understand.

4) Keep a clean model
We all should know MVC, and it's a good pattern, but the Model is the key, Understand the model as the logical representation of what you want to track. You might want a View-Model as well, to map your models to views, but keep your models clean.

These are probably the most important patterns I follow, but it's just the tip of the iceberg. As things grow though, I find myself empowered by the functionality of the system. Things tend to emerge, and new possibilities come out. There are also several iterations where I've done work at low-level core code, and significantly changed the operation of the system without breaking any of the modules or their connections, thanks to the decoupled nature.

Read More + Comments

Playing with Project Ara

2015-01-02 20:23:12.38

I had a hands on with a Project Ara dev kit today, and am looking forward to more time with it.

It wasn't a terribly exciting experience, there was 3 circuit boards, one represents the phone, the second was the bus, and the third is a sample module.

The dev kit supported several more modules, 6 I believe, but only one was included. A Blood Oximeter which plugs into the module reference board, however we didn't have documentation and were not sure where to plug the little oxymeter widget.

After plugging it all in and booting it up, we were greeted by a standard android OS screen. There was a micro-usb on the control board, but it didn't get recognized by ADB. Probably could try setting it up on the network and use Adb over TCP. Overall it was pretty easy to get running, and looking forward to other stuff in the future.

Hotswapping of modules would be difficult given the current setup, as the plugs are similar to coax and require significant time to screw/unscrew them, but nice cables.

Looking forward to building out a trial module in the future, the possibilities are endless and really will elevate the mobile platform to something new. This is the first real innovation since smartphones first started, and it's something that will allow an amazing amount of device personalization in the future.

Read More + Comments

Platform Creation: Top Level Architecture

2014-12-27 18:23:02.982

The platform is spread across two Git repo's right now, the Client and the Server components respectively. 


This is a overall view of the server, each of these groups could use their own post, but I wanted to explain it a bit from a high level
  1. Startup
    ​- Loads Global Services
    - Starts listening on port
  2. New web request
    - If registered website, goto Template handler
    - If not, goto Admin Login screen
  3. Admin
    - Loads User Space Modules
    - Each Module handles it's own Model and Services. 
    - Modules are loosely coupled, can be used for Access Control by not loading.
  4. Templating
    - Velocity binds Special Template Services located at Startup
    - Templates are parsed and served
    - Static content (media) is hosted as static.
  5. Api
    - When a request comes in and the path appears bound by the API it goes to the ApiRequestMapper
    - Api Functions found at Startup during Service Scan.
    - Parses input, invokes Api functions via reflection
    - Response is contained in a ApiResult<?> Object, standard container, and then serialized with GSON to Json, for Client use
  6. Core
    - A set of services and modules available to all.
    - User Management/Blogs/Hosting/Organization/Orders/Inventory+more
  7. Service Model 
    - ISimpleService - Basic Service, usually used at a Low level.
    - ApiService - Broker of Services for the API
    - TemplateService - Broker of Services for the Template

When you create services they typically don't have the interface you'd use in Java code, so the ApiService and TemplateService are broker interfaces typically. Implementations exist in the SimpleService for your module (which might be mocked). The Api/Template services then just use the main service to interface appropriately with the Api or Template respectively.


The client is a java side client, designed primarily for Android, but with high respect for the full stack. It's a set of smaller components.
  1. Java Library: There is a layer we don't need android, it's easier to test and portions of it are automatically generated by the server (low level communication)
    - Gateway: Auto generated communication code. Creates functions and interfaces matching the Server API
    - Service: Handles threading and state for the Gateway. Uses Guava for messaging to be Java friendly.
  2. Android LIbrary: This is for android, so the library provides some pre-built components ready to piece together a app. 
    - UI/UX Components, and Base classes to extend it
    - XML Configuration Baseline
  3. Android White Label: This is a blank implementation of the Library. It can be used as a starting point for creating a new app, and used to Test the Client/Server interfaces.
    - This is just structure, since you can't run Library Projects directly.
These Tiers on the client provide a versatile structure and a clean seperation of concerns that should allow me to rapidly deploy Advanced app's using any features of the platform. It also is very unit-testable on a variety of levels, which should aid in future web development. Using Vanilla Java should allow me to integrate in future game projects which has also been a goal.

Read More + Comments

Platform Creation: Project Management

2014-12-27 16:52:49.285

I love Agile

I've used Agile for my platform, and it's actually transitioned through 3 projects before getting where it was today. Originally YourGallery, then moved on to the unnamed restaraunt management system, it has moved on to Simple Platform as the official name.

There are various versions of Agile/Kanban I've experimented with over the past 5 years and the truth of the matter is that there is no one size fits all. Depending on how your organization is run, the processes can differ greatly. But at it's essence it's a plan-work-repeat cycle, usually with about 10-25% planning, and 75%+ implementation.


I don't mind standups, I think it's useful to define what you are doing that day and it's great for your teammates, what I don't like blabbering. Standups should be < 30 seconds a person, and most teams should be done in less than 5 minutes. It happens all to often that two members go on a tangent, and nobody is polite enough to break them up. It's not conversation time, it's a quick helper to define your day and make sure everyone is on the same page.

Story Pointing vs Estimates

I do not use Story Pointing for time estimates. The concept of Velocity is not one I really buy in that regard. Every org I've ever been at puts Story Points at either Days or Hours, or half days, or something else. Then you are supposed to use the concept of average velocity to see how much you can get done in a sprint.

However, this means that sprints need be rigid and fixed to easily pull usable estimate data out of it. I however like to do Complexity with Story Points and Time with Time Estimates. Once you are done a sprint you can compare how much time you had to how much estimated work you completed, and over time you can get a ratio and improve your estimates or adjust to the ratio.

Story points may be inline with Time estimations, but I use them to define big/small. If things are big, I don't work on them until I break them down. Once they are less then < 10sp, then I put time estimates on them.

Story points are somewhat of a meta-estimate, and they have value in defining your backlog and priorities, but I don't think they should be directly converted into time via equation.

As for how much is the capacity of a Sprint? Personally I don't run rigid sprints, I run flexible sprints based on what I'm doing. So I pick some stories, time estimate them, and then make the sprint that long.  However, once you time estimate the stories going in your sprint, you can do fixed or flexible sprints.

Sprint Planning

Obviously important, what is more important is sprint pre-planning. Going into a sprint with a ordered, detailed backlog, with priorities set and such. If everything is in order it's really just a matter of discussing the stories, reviewing the top ones and bringing them into the sprint. It's honestly not that complicated. It's the 15% design time that's required by the PM/Product people in a typical organization. If they are on top of their game, developers will always be ready to move.

Independantly I move in waves, you can see my sprint planning cycles on my flow diagram. lot's of stories are completed when I'm in work mode, when I'm in design mode lot's are created. You can see the stairs pattern in both my stories created and stories closed charts.


This is so important as a group,  in fact it's important as a individual to always reflect on things you can improve. Groups have conflict and this is a safe place to bring out your complaints. It's useful as people who aren't heard are unhappy, and this a good general step to improve communication and process. Just remember, none of us are perfect, and we always can improve.

Read More + Comments

Platform Creation: Politics

2014-12-23 16:04:53.154

This is really a minimal thing, because I don't believe much in politics, and avoid it as much as possible. However, everything has politics.

Early History

When first created, this was a project for Artists, that was the concept, however the design was generic. Eventually I found a friend seemed  who was passionately working on a similar project. I decided a merge of our efforts might be a good idea. This jumped the number from 1 to 4. 2 Programmers, a Designer and Business person. I thought this was a good recipe and went on with Project management.

It however, soon became apparent that I was bringing signifcant investment in, wasn't seeing practical gain in building the product. What I was seeing however was a focus on contracts, share structure, looking for clients and investments.

These are in themselves not bad things and all necessary, bar investments. However, the share split was incredibly disproportionate, trying to leave me with 24%, and the other dev and business guy (who were good friends) both get 26%. Since I had already put a few months in, this didn't really elate me. Especially since they hadn't contributed anything tangible. I ran sprint planning and meetings to ensure work was split, and that we as a team all had work to do, however at the end of every sprint I was the only one who finished any work.

It didn't take long for me to disolve the working relationship. I didn't want external investments, I understand that creation is investment, and that the only investment we needed to make was Time. I still stand by that, as a entrepeneur, Time is the most precious commodity, and in the end, if I was doing all the work I didn't want a ever-dwindling share in my own project.

I have a philosophy for the platform to avoid these complications in the future, and it really comes down to the following.
  • Designers: Direct sales on the platform for a commission, you set the price, I broker the sale, you get most the money.
  • Sales People: Commissions, including residuals for all sign ups

That'll cover most the economy of scaling the platform. Sales and Designers are critical for a full platform, and I'll do my best to compensate them fairly, however I wasn't ready to give up a hard significant percentage of my IP so early on. In fact, saying no and moving on was a great moment in time for me.

Lastly, about a year later, one of the guys had a kid and was working towards other things, so his investment would have been lost essentially. This is why Cliff and Vesting is a good thing, and I'd definitely use it for any future additions to the core team.

Read More + Comments

Platform Creation: Prototyping

2014-12-21 20:58:00.741

Protyping and the initial Startup

When I first heard about Wicket it wasn't so much as the official start of the project. I had started by writing some small tools and protyped web-services and then I started protyping. I knew that a few basic things had to work. It had to have a template system, it had to have a inline editor, and static content needed to be abstracted (for theming/localization)

So that was the first revisions, it was to set up the framework, the Hosting Module, the first version of the Admin, and the ability to bind content to the Templates.

Once I could bind content I made the first inline editor, it was rough and ugly, and changed the templates a bit, but it it worked. However, it was hardly a platform or something you could use day to day. You still needed external tools to manage your website and the goal is to eliminate the need for them.

Early on, I branched the platform to create various dev-tools, extending it as necessary for the job at hand. It worked well for these smaller projects, and helped explore early use-cases.

Lot's of time on best practices

Early on, I really wanted to work on best-practices, I didn't have time or budget constraints, so I set up dependency Injection, unit tests, integration tests, I designed a modular architecture that let's me add modules easily and keep them for the most part decoupled. Generic event bus messaging is used to communicate between decoupled components. When running in test mode it can dynamically inject the proper mock objects. Etc.

I spent a lot of time on best practices when I first started, perhaps excessively. A lot of the scaffolding is still in place, but I don't fully use it. However I'm happy being in the place where I can write comprehensive tests when the time is right. It is a trade off, you don't need to do everything as a perfectionist, you just need to do things good enough to be highly effective.

Following these best practices for Wicket, Java and large application development has made things easier as things grew. When you aim to design flexible software you get options as you grow, you aren't limited by rigid design.

Read More + Comments

Platform Creation: Conception

2014-12-21 19:57:22.265

This is a series of posts about the technical design, motivations and progress of the Simple platform.

Orignal Conception

The idea mostly was spawned by most the jobs I've had. They all converged on a common design before diverging again. The companies were typically software verticals, that offered a SaaS product, typically skinned/branded for their clients. The industry changes, but the common ideas and such didn't change.

Most clients want the ability to manage users, have a API of sorts, have a website and have an app, whatever their industry, a lot of the building blocks are shared and common. Users, Blogging, Security, Branding, Organization, Inventory, Sales, etc. Once these things are in place, each industry needs a few specialty features. For example, if you worked with Restaraunts for example, you'd add a module for Menu's or you'd extend the inventory system to support it. You'd add a reservation module, and then extend the app and website api's in order to support these industry features.

So Simple Platform was born, as a baseline platform not just for a blog, but for a entire platform/ecosystem. I want to make it easy for smaller business to get the software they need that is specialized to their industry. Small companies don't need SAP and other overkill methodologies, they need ways to make their life easier.

Original Technical Decisions

When I started building this it wasn't so much that I chose the technologies then they chose me. I've already built similar systems a few time in the past. WIth other javascript libraries in other programming languages. It isn't my first time around the block.

One day I went to a interview and in the process of discussing technology Apache Wicket came up. I didn't know what Wicket was at the time, but having come from a MVC style app development framework it really appealed to me over the PHP style development I'd done in the past. I got all the benefits of good practice, and the transparency and flexibility to build interesting web platforms.

However, I understand that Java and underdog frameworks don't make developer/user adoption, so I wanted a templating engine. I think in the MVC design, a good V is important, and support of Apache Velocity is what was chosen. It gives a simple language that can be easily learnt, with control over what I allowed the user to access.

So the start had begun, I took, Apache Wicket and Apache Velocity, and started coding up a web-platform based on a strong templating system.

Coming Up: The first 3 months.

Read More + Comments

Why I Love Project Management

2014-12-20 15:53:04.746

Developers I've met don't like to plan much, and the ones that do might make some UML documents and such to outline the structure of the program they want to write. Define a model and some components, and work towards that.

Personally, I think two things are important when building a project.
  1. Know the start
  2. Know the finish
The middle, regardless the size, is not necessary to worry about much. The start always moves as you progress, you are always re-evaluating the middle.

I think of software as a boat. You know how to start, and you know how to navigate, so you don't really need to plan every change up front. It's a iterative approach. Every once and a whle you check your position and fix your direction to get to your destination.

This is why I like Agile. It's very hard to know how exactly how far your destination is, but if you keep your eye on the goal, and constantly re-evaluate your direction and destination. You'll get to your goal efficiently.

I would not have been able to build Simple Platform without good project management. I had a distinctly different view of the destination then when I started. It was a far shore and I was working towards it, but as iterations have progressed the view has changed. The destination itself hasn't, the concept of what I was building has stayed the same over the iterations.

Now I feel like I'm working my way up the coast just looking for a landing spot. Each iteration is focused not on features, but usability and accessibility. I'm just looking for a place to land, and camp to set up and get it all running.

I could write a similar article about why I hate Agile, but I'll leave that for another day. It has a lot to do with how companies don't let agile be flexible, they over-plan and over-estimate it into a rigid structure.

Read More + Comments

Feedback from reddit

2014-12-20 03:38:02.69

I reached out for feedback from the community about my landing pages and platforms.

It looks like I probably had a couple hundred click throughs, and a few sign up's and trials. The information gathered however will help make the next iterations of everything.

Take Homes
  • Simplify and focus on my strengths
  • On the Hosting Page, I should add examples.
  • After signup, most people just created the website, I'm not sure how many logged in. It doesn't look like anyone actually edited their site.

Improvements to implement
  • After signup, go straight to website editor if there is only one website (common use case). So user doesn't need to click around and guess.
  • I'm going to add a list of the Themes to the Hosting website, so they can be quickly previewed.
  • Videos for the Hosting, walking through the process, of setting up a site, choosing a template and writing to your blog.
  • Video for the platform, explaining the motivation and reach.
The overall tone of the feedback is I need to drive and funnel the users through my vision and why it's good. Historically I like to overwhelm with data, but I can make it all available, while funneling users down a directed waterslide of information.

I'm also going to break it down based on whom I'm targetting, and explain to Users, Web Developers/Designers and Entrepenereurs about what it has to offer them in particular.

Part of the pledge, is to updates this blog, and write some regular content. Since I wrote a blogging platform, I think that's reasonable.

Read More + Comments

Alpha Now Up

2014-12-18 17:27:52.579

If You'd like to see more, goto and try out the platform yourself today.

Read More + Comments

Reducing Dependencies

2014-12-09 18:26:54.676

My Build.gradle was sort of a mess. Not anything terrible, but after some time you forget what you use, what you don't. So I just untertook the first reduction in a while of this file.

It's not much of a article, but I considerably cut down. I had about 8-10 repositories before, now I have 3, and they are much more mainstream which means less worrying about the build for me.

The Dependencies themselves were not reduces significantly, however everything in the gradle has a use somewhere. It's about as trim as I can get it for now.

The side effect of the cleanup of my build was improved build speeds, and less confusion. I also upgraded components at the same time.

Read More + Comments

Something in the company blog

2014-12-08 23:13:37.684

The site is up, and you can come here for news and entertainment, and possibly pretty pictures.

Read More + Comments