In which I write about my OUYA.
My son wants to write a console video game. ID@Xbox turned down our application because, well, he’s never written a video game. He’s not a Playstation player, so not that either. I dislike Nintendo. What console can he write for? The OUYA, an Android OS based game console!
In which I reiterate what's in the title.
I have a relatively difficult-to-understand and, therefore, difficult-to-maintain implementation of HAML over at gohaml. I’ve kept it “up-to-date” as Go has matured to version 1.0. Now that it has, it’s time for me to make good on something better for the open-source community.
First off, the new gohaml will pass all tests in the excellent haml-spec fork that I’ve created to run gohaml against it. As soon as I get those passing, I’ll submit the pull request to the real haml-spec for inclusion in their repository.
Secondly, gohaml has a new structure. Hopefully it will make the whole of the library easier to understand and conform more to the structure of the Ruby implementation of HAML from which all good HAML-ness flows.
In which I send you over to GitHub to look at stuff I did.
I created the houstontechfest2013 repository over on GitHub. It contains the presentation slides (with speaker notes) and some commented code that I went through during the presentations.
In which I provide steps to get ASP.NET MVC 4 running on MonoDevelop 4.1
I have newer instructions for newer tech over at Setup ASP.NET MVC 5 on MonoDevelop 4.2.
Instead, maybe you should try Visual Studio for Mac.
In which I share what I did to get it working.
I like rbenv as my ruby version manager. I plan on deploying a Rails 4 app to my own server, that is, not Heroku or Engine Yard. I want to try puma as the Web server for that Rails installation. So, here’s what I did to get everything working correctly on my Mountain Lion MacBook Pro.
- Install rbenv following the instructions of Basic GitHub Checkout
- Install ruby-build as an rbenv plugin
- Restart your shell
- Start a shell (if you didn’t restart it from the last step in the previous section)
- Set the PATH variable to the PATH variable without any part of the PATH that points to the $HOME/.rbenv directory
- Install Rubinius 2
rbenv install rbx-2.0.0-rc1
- Add the following line to your __.bash_profile__ to force Rubinius to use
the version 1.9 interpreter.
RBENV_VERSION=rbx-2.0.0-rc1 rbenv exec gem install rails RBENV_VERSION=rbx-2.0.0-rc1 rbenv exec rails new «your_project» cd «your_project» rbenv local rbx-2.0.0-rc1
In which I provide a link to a code repo for pyvisitor.
I created the pyvisitor repository over on GitHub in case you want to use my implementation of the visitor pattern in Python.
I’ve released it under the MIT license, so you can do whatever you want with it.
It now occur to me that I should have released it under the WTFPL, but I don’t have the heart to change the LICENSE file.
Hope you enjoy it.
In which I bemoan my lack of production and increased rate of consumption.
Over the weekend, I re-read three Neil Gaiman books: American Gods, Anansi Boys, and Good Omens (with Terry Pratchett). They made me smile and, at times, laugh out loud at others. But, when I finished them, a lugubrious mood settled over me. Not the one that I normally feel when completing a good book and regret that it has ended. No, I felt bad because I haven’t written anything over the past two weeks. Moreover, I haven’t written any fiction in over a year.
In which a reader points out I'm wrong, wrong, wrong.
I got an email from a reader in Spain that read, in part
I did a test and got an AttributeError. Maybe you are interested in debugging it.
The email referred toThe Visitor Pattern in Python
which I wrote in January of last year. I pulled down the code, gave it a whirl, and found that I had a bug in it.
Wrong code ⇒ bad code.
I wanted to debug it.
In which I study the MVVM so-called pattern and present a plan.
For a long time, Model-View-Controller, Model-View-Presenter, and (with far slimmer adoption) associated patterns represented the accepted patterns for the objects that participated in organizing the responsibilities found in a graphical user interface. But, back in November 2010, the Microsoft® patterns and practices team published the Model-View-ViewModel (MVVM) Pattern that takes advantage of their WPF and Silverlight user interface toolkits. Now, we have MVVM toolkits in lots of different languages and rendering targets. This post discusses the pattern, its requirements, and its awesomeness.
In which I give you a preview of upcoming blog content.
I had planned on putting up another post when Monday rolled around, one that continued the MVWTF discussion I started last week. My friend, Ed, reported that the post seemed incomplete because I dropped the MVVM ball. I couldn’t help but agree.
On Sunday, I started the MVVM post. However, it has run away from me. Far, far and away. I have put about 12 hours of work into the post and I’ve only half completed it. This has not resulted from an immense amount of content; rather, it has resulted from trying to create precise content. To quote Dr. Andre de Korvin, “We must lose precision to make significant statements about complicated systems.” Well, I ain’t losing no precision, here, so my significant statements take longer.
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!