I just got done reading yet-another-article about knockout.js. Unless you’ve lived under a rock for a while, you already know about knockout.js. This is NOT another article on knockout.js. The author of the article decided to spend 600 words explaining the differences of MVC, MVP, and MVVM so the reader could understand the pattern adopted by knockout.js. I think he got a lot of it wrong. That’s why I really want to talk with you about MVC, MVP, and MVVM, their histories, and their differences.

I have this blog, right? I host it with GitHub Pages, right? To do that, I have a repo named «realistschuckle.github.com» which redirects to curtis.schlak.com when someone types it in. Turns out that migrating that to another repo didn’t work.

I created that repository back on 5 December 2011. The instructions, at that time, directed me to name it «[username].github.com» and that’s how I get my custom GitHub Pages site.

Awesome.

Because of the

GitHub Pages, I have spent a lot of time in their documentation. During that reading, I discovered that the new naming convention goes ends in «.io» instead of «.com». On the page Should I rename <username.github.com> repositories to <username.github.io>?, they instruct that

If both a username.github.io and a username.github.com repository exists, the username.github.io version is used.

To host my blog’s content, I figured I could just create a repository named «realistschuckle.github.io», host the locally-generated content from «realistschuckle.github.com», and all would work correctly.

Nope, it did not work correctly.

Last night, I sat down to investiage my jekyll and Github Pages problem. I made a change that reverted most of my content for the blog, pushed it, and GitHub Pages built my content like a champ.

I made another change and pushed it.

…

…

…

Nothing. GitHub Pages failed to rebuild my content. I sent an email to the exceptional GitHubber with whom I’ve dealt and he replied with the following:

I’m sorry to tell you, but I think you’ve stumbled on another bug. It looks like Pages aren’t rebuilding when the pushes happen so close together. I’ve opened another Issue for our team to figure this out. Hopefully, we’ll get this fixed up soon, since I’m also unable to trigger a rebuild on our end.

Bummer. He said that if I want the content up, I should just build it locally and push the generated content, instead. So, I’ll do that, for now.

Hopefully, you’ll see this content. Sometime. Soon.

I still ♥ GitHub.

It turns out that I have somehow managed to introduce an edge case in my blog’s content that causes jekyll to fail on the GitHub Pages server. It all runs fine on my machine. It runs fine on a GitHubbers machine. Just not on the Pages build server.

It fails with this helpful message:

error: interning empty string.

So, now I’m trying to fix it the old fashioned way: incrementally.

I don’t know why, but my previous front page started to offend me.

Now, I have a newer, uglier front page.

The continued uglification of my site will continue.

Vive le truand!

I just updated this site to use jekyll v.1. It builds my site faster which is good during the local development of a new posting. It also has better messages about the build, including a “done” indicator which the last version I ran did not have. Here’s some actual output from saving this file:

Regenerating: 1 files at 2013-05-17 11:35:36 …done.

That’s awesome.

The best feature, by far, is the support of the _drafts folder that contains works in progress. Previously, you had to specify the date of the post for a future date and use the --future option to get those included in the site build. Too much work!

Now, just put a new markdown document in the _drafts folder and they show up at the top of the list using the file’s last modified time. Awesome!

If you have a blog and want to use something other than Wordpress, try out jekyll and use GitHub Pages to host the content.

Easy peasy lemon squeezy!

Ok, so, I’m a purist. I like things to do their job, do it well, and not reach beyond their boundaries of functionality. In this case, I refer to jQuery UI and knockout.js as the things under conideration.

I think that each library has a strength that I want to use in my Web application:

jQuery UI

Used to create widgets and handle events like mouse clicks.

knockout.js

Used to bind values from JavaScript objects to HTML nodes (and back again).

The problem

With that in mind, I encountered a “problem” with getting the two to work seamlessly with one another specifically around using the jQuery UI Datepicker. When a user selects a date from the calendar control, the Datepicker sets the value of the associated INPUT node with the selected date.

How does it do that?

I’m reading Inferno by Dan Brown of The Da Vinci Code fame.

I don’t like it much. It does hold my attention more than The Lost Symbol. Barely.

Oddly enough, its main plot device is the same plot device I wanted to use in my own untitled novel planned a couple of years ago but never written.

If I write it now, everyone will just say, “That’s so derivative.” And, in anything other than calculus, derivative just ain’t no compliment.

Oh well. Opportunity lost.

See you tomorrow.

Sixty-six books.

Woe is me.

Woe is my bookshelf.

Woe is Seymour Lipschutz who wrote my set theory book.

In this article, I show my total design for the athletic club exercise. You could have totally figured that out from the synopsis for this post; however, since you, dear reader, only remember 30% of the crap that you read, I’ve now upped my chances of sticking in your cerebrum just a little bit longer.

This post concerns itself with identifying the participants in our domain model that we have not classified as «moment-interval»s. That means we’ll look at «thing»s and their associated «description»s and «role»s. But first, I want to recap what we’ve completed so far over the past couple of days in case you’ve jumped in mid-series. If you’ve followed along, however, you can jump to the new stuff.

In Java Modeling in Color with UML, the authors define the «moment-interval» archetype as

something that one needs to work with and track for business or legal reasons, something that occurs at a moment in time or over an interval of time.

Originally, Peter Coad called this archetype «transaction»; however, this caused a lot of confusion in the programming community due to the implication that “transaction” meant “business transaction”, like a sale or a purchase. Coad actually meant the purer definition of the word as an exchange or interaction between parties. Because of the confusion, he renamed the archetype from «transaction» to «moment-interval», a more cumbersome phrase with a neutral meaning.

This post discusses finding «moment-interval»s in our problem domain and using them in our object-oriented designs.

I think the stuff from yesterday's post kind of sucked. Sorry about that. It seems that my perishable skill of writing nears six feet under. I’ll endeavor to make today’s post more lucid, cohesive, and informative. Perhaps that will revive my chosen word.

I told my nascent development team that we would use modeling with color as our object-oriented design philosophy. Then, I reserved a conference room for four mornings so we could learn this practice first hand. I started by showing them the following list of user stories.

• People join the club to become members and get invoiced monthly a flat fee and participation fees for classes
• Participation fees for classes consist of a prorated amount of the instructor’s hourly rate and a percentage of the cost of the equipment used by participants in the class
• Record member purchases of food and beverages from the club for rewards
• For every ten dollars spent on food and beverages from the club, the member receives a one dollar credit on their next invoice.
• Members RSVP for classes and their arrival is recorded
• Instructors schedule rooms and equipment for classes

Then, I asked them to break out in groups and create some static class diagrams that model the problem. From three groups, we had four designs emerge. They all looked like candidates for creating software to address the user stories. However, they all looked different. They all lacked some transactional information. Nothing wonky, mind you. Nobody forgot to include a Person class. But, this project that we’ve launched will grow in number tenfold over the next year; I want the code to look and feel the same regardless of who wrote it and when they wrote it. Modeling in color to the resuce!

Over the past six years, I’ve tried to apply the lessons from Eric Evans’ book with regards to collecting requirements from customers and, then, building a robust object-oriented design that embodies those requirements. I have had quite a bit of success with domain-driven design and can attest to its strengths. However, when I started using Evans’ recommendations, I had already spent the previous eight years honing my OO acumen, decomposing real-world problems into software-based solutions.

As you may have noticed, I haven’t written in a while. Between bringing home the bacon, eating the bacon, and riding around on another porcine entity, I haven’t spent time tending this little word garden. Yeah, shame on me. But, I recently spent some time talking with my nascent development team about object-oriented design and how they should perform it as we move into a business-focused cycle of coding. I wanted some process that would provide a standard by which they could enter into the practice of OOD and come out the other side with philosophically similar designs.

What to do?

Sitting in my office, I looked over at my Bookshelf of Broken Technologies™ and spied a book that I hadn’t read since the early 2000s: Java Modeling In Color With UML: Enterprise Components and Process. I vaguely remembered something about Post-it® Notes. I read the book through and sat back amazed.

This was it! An easy-to-understand, attainable OOD philosophy. With examples.

Let me write that, again. WITH EXAMPLES!