It's been a while since I've posted here so... how about an end of year recap for anyone interested.

  • Red Pill Development changed it's name to Red Pill Now with a whole marketing campaign around it
  • I spoke at MWLUG and ATLUG
  • I started messing around with Polymer Web components and think this is the way web development should be done.
  • I did a couple of training sessions on Javascript and Backbone/Marionette
  • Red Pill hired a creative director, Bob Kadrie and is contracting with a new developer from the JSF/Web Components/Javascript world, Kito Mann
  • Red Pill became a Microsoft partner
  • Red Pill redefined our Graph Database to be more relevant for analytics AND design meta-data
  • We did a web site for the Vatican... yes, that Vatican (we did others, but this one was the most interesting)

Now, to ramble on about Web Components..... So web components allow you to define your own custom html tag that can be anything you want. It can have it's own functionality, visual representation, styles and logic. I'm using Polymer Web Components which is created and maintained by Google. You get a lot of components already created by Google available for you to use which are really good. There is also a growing open source population around this technology. It's possible to create an entire application with Web Components, you just end up creating a lot of custom components. While that's really not a limiting factor, it can get out of hand really quickly. So I know you're asking, does it work on all the browsers... well, yes it does. While it does take a little more effort to get them to work nicely on Safari, all the other modern browsers do really well with them, including IE 10,11 and Edge.

So, there you have it. A high level overview of the past year. Hopefully I can start blogging here some more and hopefully start moving XBlog over to using Web Components and a better API.

Until next time, happy coding.


I am truly saddened and devastated by the news I received today of the death of Tim Tripcony. I would like to express my heartfelt condolences and sympathy to Tim's family and friends. I would also like to explain how Tim helped change both my personal and professional life. The loss of Tim has already left me feeling a rather large empty space where he once stood.

Before I was hired at GBS I learned a lot from Tim's blog and the few chat sessions I had with him. I had never met him personally, only from our brief interactions online. However once I was hired at GBS my official goal was to "duplicate Tim". His title there was XMage and mine XPrentice. I worked directly with Tim and was mentored and guided by his experience and knowledge. He constantly kept "throwing me back to the deep end" of XPages development and pushed me to better my development skills. During the Transformer project, we brainstormed, asked "wouldn't it be cool if....?" and pontificated life's and technology's intricacies. I confided in Tim as a friend and he helped me better understand some of my personal issues.

One of my favorite stories about Tim: Toward the end of the Transformer project we both started implementing the same thing and didn't realize it until I inevitably had to ask a question of him. Upon inspecting my code he showed me what he had started to write and it matched what I had written almost exactly, same variable names and logic. Seems I had accomplished at least a part of the official goal as it was shortly after this that I was placed in charge of the North American team so Tim could move on to other more complicated tasks.

After the Transformer project, Tim was one of the original co-founders at Red Pill Development. He helped guide us and come up with a lot of the Red Pill methodologies. Once he moved on to Best Methods, we continued a tradition set at GBS for "Lunch Scrum" where we all get together every week for lunch and just to visit with one another. We still had the "wouldn't be cool if...?" questions and pontificated life and technology, talked of our current conquests and defeats. I don't know about the rest of the team, but Tim's presence certainly helped settle me down some during some of our most stressful times.

I will certainly miss Tim. His easy going nature, witty responses (though sometimes over my head) and movie reference jokes will forever be with me. I am a better person and developer by having known Tim and the "YellowSphere" will never be the same.

Posted over on SocialBizUg - Popover to Google Maps

A couple of weeks ago I started messing with Titanium Appcelerator. Coming from Domino Designer and Eclipse the IDE will look very familiar. It's eclipse and it's based off of Aptana Studio. I guess the biggest issue to being productive is the learning curve for the API. But honestly when is that not the case?

So starting to delve into this, Titanium apps are purely client side javascript based. You write the CSJS that builds the UI, Business Logic, Layout, everything. While this may seem daunting at first it actually makes pretty good sense I think. If like me you don't like large javascript files it forces you to think in a more OOP mindset. Now some of you are saying "but CSJS isn't OO". Au Contraire my friend. There are a couple of different ways to approach OOP in CSJS. You can have a file where each file is an Object or a Function which returns an Object. Just follow the Singleton/Closure pattern. A perfect example of OO Javascript is Dojo, just to put things into perspective. But OO Javascript is another topic for another day.

The installation of Titanium is pretty straight forward. Download the .dmg file, run the install pkg and follow the prompts. Now I did hit one snag here, when I tried to install the Android SDK it complained about not being able to find Android SDK API 19. I just deselected this and finished the installation and then updated Titanium and it selected that API 19 for me and all was well. This was really the only snag I hit. Also be aware that you'll need to download and install xCode from the App Store in order to get the iOS simulators (iPhone and iPad).

Once this was completed, I was able to delve right in and create my first 'Hello World' app and then start adding to it as time goes on. Of course me being me I figured I would use the most complicated thing I could think of as my first project. I decided to start replicating the functionality of redpill Now. This has prompted adding to the functionality of redpill Now, mainly a rather robust REST service which is smart enough to traverse a graph db. This REST service delivers all of the content needed to provide the data for a mobile application as JSON. This will also be taking advantage of the org.openntf.domino api  for iterating over collections, view entries and of course the Document.toJson functionality.

After you make changes to your code, you can fire up the iPhone, iPad or Android simulators right from within Titanium. This is a very handy feature, tho I'm still fighting with troubleshooting. The eclipse debugger is included in Titanium and it works as one would expect it to work. I think this is a very nice touch. You can also install to a device right from Titanium. I haven't tried this yet. 

So far I've been able to replicate all of the lists in redpill Now. While these lists are not yet as refined or as intelligent as the base product, they are getting there. Next in the learning curve will be posting to the REST service and dealing with forms. Hopefully in the coming weeks I'll be able to post some screen shots and code of my progress.

While going through this exercise, it has made me stop and think a bit. Looking at the Connect 2014 sessions, maybe this is a good path to start going down. I mean, the IBM Notes client is becoming less and less relevant as the years go by. Also, it seems that IBM isn't providing as much emphasis on the "Lotus" products as they once did. I'm still undecided if this is a good thing or not, but my gut tells me I need to start moving some eggs out of the IBM Notes and Domino basket. Not to mention, learning a new technology is fun and challenging. Plus, it forces you to think differently which makes you a better all around software engineer. Which is always a good thing.

OK, so today is the 2nd day I've spent with the Mobile controls from Domino 9.0.1. I must say the lack of a 9.0.1 Beta is quite obvious. So some of the "improvements" IBM made to the mobile controls are the addition of onBeforeTransitionIn/Out onAfterTransitionIn/Out. While these events are sorely needed, the implementation IBM chose to use doesn't work is kind-of odd.

So, a brief rundown of the transition events pre 9.0.1. I posted a while back about how to implement these methods in your mobile application. Short version is do a dojo.connect to attach to the needed transition event of an appPage. Then in that function make an RPC call to do any server side processing that might be needed. This initiated the following chain of events:

  • An HTTP POST request was sent that ran the RPC Method
  • The page moved to the destination page
  • onBeforeTransitionIn fired a partialRefresh to refresh the content of the destination page

This series of events still happens, kind-of, just not in that order. The events now process in this order:

  • A partialRefresh of the destination page happens
  • An HTTP POST request is sent that runs the RPC method
  • A is fired which is supposed to move to the destination page

If your content is static and not programmatically determined, this is fine. But otherwise this is all wrong. Why is a partialRefresh firing before the POST? The POST is what determines which markup is to be shown on the destination page. With the partialRefresh happening before the POST these events and almost the components are now useless and it breaks any previous implementations of these events.

There is a work around for the moment that works to a point. The only place I've found that it doesn't work is if there is a dataView on the destination page and the dataView's configuration is programmatically determined (works fine if the configuration values are static). The work around is to add a callback to the RPC call with a partialRefresh of the destination page's first child element. Don't even try and use the events defined on the appPage component. So, if you watch the network traffic you'll see a GET then a POST and then another GET. This does however introduce a pretty good performance hit.

I think it's great that IBM listened to the community and added these events. However, it seems pretty obvious that the community wasn't given the chance to find these issues before the release. I think it also shows that these events weren't tested properly in a real world scenario. I guess if the events were called onBeforeBeforeTransitionIn/Out and onBeforeAfterTransitionIn/Out it would've made a little more sense.

Just posted over on SocialBizUg a tutorial for putting together a responsive layout for your XPage Applications.

On SocialBiz User Group - The Modern Notes Developer