|Latest 7 Posts
| Docker Quick Tips|
Fri, Apr 28th 2017 86
| Notes in 9: Dev Tools Grab Bg|
Tue, Apr 4th 2017 8
| Custom JSON Serialization With GSON|
Mon, Jan 23rd 2017 10
| Recapping 2016|
Mon, Jan 16th 2017 9
| Rebirth: An App of Ice and Fire|
Wed, Dec 14th 2016 7
| Scripting Server Upgrades|
Fri, Nov 11th 2016 7
| Everything Old is New Again|
Mon, Oct 24th 2016 7
| Docker Quick Tips|
Fri, Apr 28th 2017 86
| Building Java Objects From JSON|
Thu, Jan 22nd 2015 13
| When You Need a Comparator|
Thu, Jan 8th 2015 11
| Notes in 9: Docker + SonarQube|
Wed, Feb 24th 2016 11
| Nerdy Yet Awesome|
Fri, Feb 26th 2016 10
| Custom JSON Serialization With GSON|
Mon, Jan 23rd 2017 10
| Recapping 2016|
Mon, Jan 16th 2017 9
| REST is Best|
Wed, Sep 17th 2014 8
| The Road Goes Ever On and On|
Mon, Jun 22nd 2015 8
| 2015: A Year In Review|
Tue, Jan 5th 2016 8
||Blue Chalky Soup
Blue Chalky Soup
This is the code name I gave my boiled down session to keep it more in fitting with IBM’s description of a Chalk Talk, I got interesting with things. Specifically a reveal.js mini presentation (mostly so I could give people further reading or references and resources), served by a Node.js/Express app, with live updating presenter controlled slide state, triggered via a web socket. I am clearing my queue, as it were, so here is a link to the repository with my code base on GitHub.
Note: the basic authentication represented in the code and in the ReadMe.md of the repository is not what is in my Bluemix deployed version of the app. The reason for that is that I don’t want to encourage people to use my live one outside of my 30-day trial (more on that further down). What this repo does do is provide the code base so that if someone else wanted to implement it, they wouldn’t need to go through the same hackery I did, to get the right combination of elements to work (EJS, slide state push by web socket instead of change event only, and current versions of npm packages).
If you’re not interested in learning about my Bluemix experiences, then you can feel free to stop reading now. TLDR; I like what Bluemix does and can(/will) do, but there may be a way to make things easier for customer adoption, from the developer’s perspective. For more on this, just scroll to the end of the post.
Some Bluemix Thoughts
I deployed my nifty one-off app to Bluemix, as mentioned above. I’ve done the same in the past with a digital version of my resume on heroku and a simple (but custom) feed reading app on a node instance (which presents the full HTML content from RSS or Atom feeds, in a Bootstrap 3 layout, with app caching for minimal load while reading from a mobile device), hosted on OpenShift; strangely enough, I’ve not dabbled with AWS Elastic Beanstalk. These few apps, while somewhat trivial, let me play with the major PaaS solutions I had seen as easily accessible to developers, and capable of scaling in demand to meet business needs. This was before Bluemix came about (initial release was Bluemix was the end of June 2014), so when given the opportunity to deploy something to it, I was happy to do so and try out the platform, even if in a limited capacity.
The available run times are pretty comparable to the competitors, with notable exception (from my perspective) being the upcoming XPages build pack (.xsp run time and Domino Data Service, both of which are very exciting for very obvious reasons to any Domino/XPage developer). I’m sure I’ll post again once I’ve had my first taste of deploying an XPages app to Bluemix, and I can’t wait to do it.
This tweet, take live from IBM ConnectED’s Domino Applications on Bluemix session, shows how the runtime fits into the architecture of the application.
For a more thorough look at run times and services offered by a variety of providers, by all means check out something like paasify.it, which gives a good look at the run time environments and services offered by each PaaS they list. Be forewarned, I felt that the Bluemix information was either a little outdated or that it just didn’t map well to the model of information listed (each PaaS has different units of measure, like gears, workers, or RAM and instances, as Bluemix uses). If any IBMer stumbles across this, paasif.it says they welcome pull requests on their GitHub repo to the pertaining .json file under /profiles; in the case of a need to update information.
Bluemix’s runtime offerings are fairly robust, with room for more and custom build packs. This is definitely a win, in my book.
I was happy to see a number of things in my Bluemix account’s dashboard. Specifically, when working with heroku and OpenShift, I found their terminologies of “gears” and “workers” more confusing than not. A developer can look up the definition and equate it to something in their head, but with Bluemix, you look at your dashboard and you can see how much RAM each instance uses and how many instances you will allow it to scale to, out of your max allotment. These are terms that those who don’t understand the cloud can grasp, and makes it easier on my part as a developer to sell my management to the platform. Chalk that one up in the success column.
Bluemix Use of Cloud Foundry CLI
Both of the other two PaaS services I’ve tried and used include a command line tool for managing your cloud deployment and deployed app management; in addition to the web interfaces they provide with some of these tools. The power given by Bluemix’s use of the Cloud Foundry CLI tool is impressively easy to use by any developer. With heroku, there’s the heroku toolbelt, and with OpenShift, there’s the rhc tool. As a comparison, it’s probably on-par for ease of use, but maybe it’s my being more accustomed to these PaaS CLI tools, but I found my use of the CF CLI was a very quick learning curve, with minimal fuss. Once more, success in meeting in the industry standard on CLI tools.
Getting Started With Your App
The Cloud Foundry CLI isn’t the only way to deploy to Bluemix. You can also use a plugin for Eclipse (I saw a version demonstrated with the Domino/XPages on Bluemix session in DDE!) or automate the deployment via a git repository through IBM DevOps. There’s a solution for every need here. The only upside to the CF CLI tool is that it is agnostic to the git branch you are on, so you can take your current, working set and just push the files (which it bundles into a droplet) to Bluemix’s servers. The ability to deploy by git, CLI, or Eclipse plugin (including for DDE and, I assume, the other Eclipse-based IBM-specific development environments) make for another win.
Integration With DevOps
One handy feature is the ability to connect from DevOps. This means you can push your changes to DevOps via the master branch of a git repository that can trigger a build on Bluemix. This integrates services across IBM’s spectrum of cloud solutions and was pretty easy to use. I tested it, even though I had to re-add my files to the git repo for DevOps as it semi-forced me to take a starter app when I initialized the repo, as the Bluemix app was created first; which seems to be out of their preferred sequence. In other words, if you’re going to use DevOps, start things from there and tell it to enable Bluemix deployment. Not everyone uses DevOps, but it’s something that I would give some serious consideration to, considering my trial’s ease of implementation; another win.
Preparing Your Applicaiton for Production
Obviously, in a pricing scheme which relies on GB-Hours as the unit of measure, you’ll want to scale your application to the needs of its use. As stated in the Domino/XPages Applications on Bluemix session (and elsewhere from IBM), there will always be a free tier for an application. There’s a caveat to that, which I’ll get to in a bit. When you’ve got it set up and running, it’s an impressive thing to see.
Bluemix’s Trial Account Comparison
So I think there’s an excellent argument to be made that Bluemix is a significant contender in the PaaS market, with great ways of deploying and maintaining applications. The argument can also be made that IBM offers some unique options which make them a go-to for use by existing and new users of their systems; specifically in the Domino Data Service + XPages runtime and Watson driven services, respectively. There’s just one thing bugging me, and it’s this.
My initial trial account, which is tied to my IBM ID, has a 30-day window in which I have access to up to 4 application instances and 2GB of RAM. This is pretty darned powerful, more than I needed to setup and sell myself on the platform. But I’m playing the long game with my development management team, who having been RPG developers with less knowledge of how web applicaitons work, make for some intersting conversations on occassion. In order to sell the platform to them, I need to be able to do what I’m doing now, as I’m half-way into my 30-day trial, at some point when they’re ready for the conversation (and I’ve got them prepared to accept “the cloud” as a solution); probably within a year or so. I could roll a different ID, but this is my IBM ID, it’s me, and that would be silly. I’ve heard that applications will have a free tier, but once the free resources are consumed in a month, something will happen I don’t want; I’ll be charged. This is unique to Bluemix, that when my 30-day free trial comes to an end, the account becomes freemium, with my credit card needing to be on file.
Why can’t we just have a free account that doesn’t incur charges? There must be some other way in between; the other guys are doing it. In fact, the way heroku tends to work is, if your account is of the free/developer flavor, they’ll shut down your running instances after a period of inactivity. This incurs a bit more instantiation (and wait time) by the first user of that application after it was inactive, but still provides for a purely free mechanism. The organization (hierarchy inside of Bluemix requires an org) of “Eric McCormick” shouldn’t need to pay for that hair brained developer Eric McCormick’s wild online blogging success, should a test/demo app URL ever leak (case in point, even if I had to cheese it up there). This is where IBM comes just short of what I would like.
“Just One More Thing” IBM Can Do
That being said, I am fairly well sold on Bluemix. It maps very well to where I think a few of our critical, high volume applicaitons should be in a year to two’s time. It maps well to our existing application structures, including the pending Domino Data Service, which makes for an easy sell with regards to what hopefully could lead to on-premises replication of data (be it app data storage or names.nsf sync) and the XPages runtime (application format that they already know about) in addition to Domino Data Service being usable outside the XPage runtime (e.g.- Node.js or Java Liberty; these are exciting times!). It’s also a PaaS offering from IBM, a company which mine already knows well, as opposed to the competitors, which they wouldn’t necessarily think/know of. These are things that help in selling the platform to my management. This all leads to my request. For us, IBM platform developers, to either:
- not need to enter a credit card for a free account (cripple what we can have after the 30-day trial, inactivate idle sessions, something, anything)
- configure our account (with credit card on file) to inactivate when idle or halt applications at the point of charges would incur.
I’m honestly not trying to sound like a cheap college student (he’s still inside, somewhere), but if IBM can let us do one or both of these things, Bluemix adoption rate will only benefit from it.
I really like what Bluemix is. I would love Bluemix if it can fit all my needs, especially in selling the platform to my company and bringing our app development ops to the next level (and fulfilling my wildest dreams).
Feb 02, 2015
| Recent Blog Posts
Docker Quick Tips|
Fri, Apr 28th 2017 3:00p Eric McCormick
Docker If you have been living under a rock, Docker is pretty much amazing. If you haven’t been living under a rock, you may be getting used to the idea of Docker, but still have the occasional question. I’ve found myself using Docker in increasing amounts and complexity over the last year or so. I’ve recently decided to start recording some of the tasks I’ve found useful, some of which may be less familiar to a beginner. If you’re so inclined, check out the playlist, embedded here.
Notes in 9: Dev Tools Grab Bg|
Tue, Apr 4th 2017 1:00p Eric McCormick
Intro I’m on Notes in 9 again, with a “grab bag” of a couple of tools I’ve put together recently that may be of a varying degree of useful for other Domino + XPages developers. You don’t need these to do development, but for the right person, they may help with their development workflow. Also of note, with the upgrade to Swiper with the FP8 release of Notes + Domino Designer, the limitations previously mentioned are no longer there! This means that my second tool I talked about, node-
Custom JSON Serialization With GSON|
Mon, Jan 23rd 2017 2:00p Eric McCormick
Mon, Jan 16th 2017 3:00p Eric McCormick
Per usual, I’ve had a little break between things and decided to catch up with a bit of a summary of some recent things that each didn’t necessitate their own post.
2017 IBM Champion
For starters, I’m honored to be named an IBM Champion in Collaboration Solutions (/ Social Business) for the third time. This would be a hat trick in (ice) hockey 🏒. I’m happy to be recognized with a group of people, developers and more, who are passionate about both their work and the plat
Rebirth: An App of Ice and Fire|
Wed, Dec 14th 2016 4:00p Eric McCormick
If you read my blog for any of the Saga of Servlets series, then I hope that you’re excited I’m returning to the application I put together for it. This time, it’s as a conversation piece in regards to some of the build process modernization I engaged in recently, in order to unify the code base in its git repository. In any case, it’s helping pave the way forward before I update some of the back-end elements, when it will again be a talking point for some additional rework and
Scripting Server Upgrades|
Fri, Nov 11th 2016 2:00p Eric McCormick
This one might be slight departure from my usual, but those that have followed my blogging this past year will have noticed a bit more of a leaning towards DevOps in some of my posts. This echoes a lot of what I’ve been concluding as increasingly a necessary part of development; that we need to consider a picture large enough to encompass the themes surrounding development functions and, like any good developer (DRY ~= “lazy”), automate the heck out of it.
I had p
Everything Old is New Again|
Mon, Oct 24th 2016 8:00p Eric McCormick
Every so often, it’s good to reassess one’s position. This is good from both a standpoint of being inquisitive and even interrogative, but when it comes to the ever changing landscape of the front-end development space, it’s not only inevitable, but must be embraced for what feels the need to “stay afloat”. I’m changing theme of my blog, hopefully for the better. The previous theme was good and did a great job of getting things started, but while I had forked a copy of a good
Thu, Oct 20th 2016 8:00a Eric McCormick
If you’re just here to learn a little about how to “squash” commits with git, skip down a ways. Otherwise, hold on, and I will catch you up on a couple of personal notes before we get there.
On the Blog
It’s been a little while since I blogged last. This has been due to a combination of reasons; specifically, I’ve been busy with:
my family, it was the end of summer with lots of things going on
a number of projects around the house (a deck removal and basement remodel
Wed, Aug 24th 2016 8:37a Eric McCormick
MWLUG was a great success as far as I’m concerned. Each time I’ve gone I’ve had the great enjoyment of being able to attend some high quality sessions, meet with lots of colleagues and friends from the community, and get a view into products and solutions many people are undertaking, over conversations and interactions outside of the sessions. This is always a great way of interacting with others who were able to make it. Unlike the IBM conference of Connect(EDsphere), this is purel
Manually Renewing HTTPS w/ Let's Encrypt|
Wed, Jul 27th 2016 10:40a Eric McCormick
A while back, I rolled a personal project, which is a Node app, to Bluemix for lightweight use. I managed to make use of Let’s Encrypt for the HTTPS certificate, but only after realizing that there was a bit of a manual aspect to it that is the antithesis of an automated script for such things. Ultimately, after finding some information in a blog post form Marky Roden (of all people), I was able to get moving. The only downside wound up being that time passed, and it came time to renew