In which I get all pedantic about MVC, MVP, and MVVM.
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.
In which I warn you about renaming GitHub Pages repos that back custom domains.
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.
Because of therecent problems with
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.
In which I find another bug in GitHub Pages.
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.
In which I explain where everything went...
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
It fails with this helpful message:
error: interning empty string.
So, now I’m trying to fix it the old fashioned way: incrementally.
Look at this new ugly front page!
In which I note the new feature of jekyll that I really like.
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.
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!
In which I reveal a solution to the fundamental problem of unifying the libraries.
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.
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
INPUT node with the selected date.
How does it do that?
In which I tell you to be quiet.
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.
In which I list the contents of my professional bookshelf.
Woe is me.
Woe is my bookshelf.
Woe is Seymour Lipschutz who wrote my set theory book.
In which I present my full model for the athletic club exercise.
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.
In which I discuss identifying the «description»s, «thing»s, and «role»s in our example
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 which I discuss the "timeline" core to modeling in color.
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.
Considering the first step of modeling in color.
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
The first in a series of entries talking about Modeling in Color
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!