I've made a couple structural changes to the blog here. Normally, I wouldn't make a fuss over things like that, but they're pertinent to the overall theme.

First off, I changed the links over on the right, adding a link to the in-progress home page of my side-project company, I Know Some Guys. We're in the market for contracts - web site projects, internal apps, and the like. I may have more about that later.

I also promoted the link to my portfolio page to its own category. Since the aforementioned side-project company isn't a full-time gig, it can't hurt to keep that and the resume visible.

Finally, the blog itself is hopping on the ever-popular Bootstrap bandwagon. For the most part, the look of the site should be the same, though some widgets here and there are an awkward mix of the two. Many of my projects lately have been Bootstrap-based, and I figured I may as well move this over too, but not just leave it at the default style. Not only is the site (somewhat) more responsive now, but it and the portfolio have been giving me practice with building controls and Themes to make the application of Bootstrap to XPages apps easier. One huge advantage of OneUI is that IBM did a lot of work theming standard controls and building excellent new ones in the Extension Library to automatically gain OneUI styling as appropriate. Fortunately, I can piggyback on that: with a bit of work with Themes and Renderers, my goal is to make it so that an app can be almost-seamlessly switched between OneUI and Bootstrap as desired. They're not perfect matches for each other (OneUI has more structural geegaws), but they're close. That'll give me some much-needed Renderer practice, too.

As I alluded to in my previous post, I decided to set up a "portfolio" site to house a list of projects I've made or collaborated on and my recently-updated resume:

http://portfolio.frostillic.us

The site itself is intentionally quite simple: it's meant to house clear content, while further details are available on linked pages. Nonetheless, despite its simplicity, it's allowing me to further refine a couple things I've been tinkering with lately:

• Bootstrap. Collaboration Today came out of the gate with a very clean implementation of a responsive Bootstrap design, and so I've been following suit by using Bootstrap for my non-data-driven sites (OneUI still feels like a better choice for complex applications in XPages). This portfolio provides a perfect testing ground for thoroughly incorporating the standard Bootstrap elements and making sure everything looks good and works properly on mobile devices.
• Bootstrap as a Theme. This goes along with including Bootstrap generally, but I figured I'd take this occasion to start making a clean Theme to handle including the appropriate files and applying useful styles that I come across. Currently, this mostly means button styles, but I could see this expanding and potentially including renderers so that you could apply Bootstrap in much the same way that you do OneUI and standard and ExtLib components (like navigators) would adapt accordingly.
• Cleaner URLs. I mentioned this in the aforementioned previous post, but I want to look for ways to keep XPage URLs as clean as possible. For this database, I'm taking a cautious route: using Domino web rules and giving the database a little knowledge about them, rather than exploring the possibility of running the whole site from a servlet. For a simple database, this is working well, with a basic from/to map and a simple manager bean.
• Aggressive Open-Sourcing. Most non-work apps I've written lately have found their way to GitHub, but I decided I wanted to further drive the point home on the portfolio site. Towards this end, I included a "View page on GitHub" link in the footer of each page that links to the current master branch version of the XPage.
• Page Controllers. I mentioned this a bit before, but I'm including my "page controller" idea in the portfolio, at least for editing documents. I created an AbstractDocumentController class that is meant to be a parent class for controllers used on pages with a single document data source. It just provides a couple convenience methods and hooks to override in type-specific cases or use directly in the basic case.
• Another Simple View/Document Wrapper. This one isn't really anything new, but it's another example of how frequently it's useful to write a model class and manager instead of dealing entirely with the views and documents directly on the XPage with SSJS. The models make it clear what the important data is and the resultant XPage is pleasantly clean.

All in all, this has proven to be a good exercise in writing a focused, simple XPages app with an eye towards extreme cleanliness.