Tag: JavaScript

EmpGrid Post-Mortem (and Resurrection!?)

Jeroen

This post is about my pet project EmpGrid. But first a short story about how I work.

About Promises

I try to be extremely precise with promises. In fact, you could say my Promises work very much like the native JavaScript promises. Let’s look at some code:

We can note some things about that code:

  • The promiseSome(thing) bit should always complete successfully, and always return a real, concrete promise;
  • After that, the then(...) bit will be executed nearly always, i.e. typically a promise resolves successfully;
  • Only in exceptional cases, with a typically well-defined error, will the catch(...) occur.

And that is exactly how real-life promises work for me too. I want people, most notably me, to be able to count on a promise being fulfilled (given normal circumstances).

So, why is this relevant to EmpGrid? Well, I promised myself this for 2018, Q3:

Finalize EmpGrid: finish it XOR do a postmortem

So, this post is that finalization. Because I promised!

EmpGrid Post-Mortem

Since I have not fully finished EmpGrid, the only option I have to fulfill my promise is to write a post-mortem about it.

The idea behind the project remains the same since its inception. It should be a self-contained web application that shows for a group of employees (colleagues) where you can find them online. Typically, you’d be interested in all their “Presences”, ranging from social media (Twitter, LinkedIn) to version control sites (GitHub, GitLab, etc.).

The intended side-effects of the project also remained the same. The repository should be slightly over-engineered, since it should serve as a playground to test technologies useful in larger applications. At least for the server-side bits; client-side a first version could do with a very simple monolithic single page application.

If you clone the repository today, you get a mostly functional thing. You should be able to run it out of the box (given you have a modern .NET Core development setup), and do some CRUD stuff. However, it is not at all “finished”. So, I’m declaring the project dead today, Saturday, September 22nd, 2018.

Here’s what’s still sorely missing:

  • Some kind of user management. Currently, you can only use the built-in seeded admin user with default password. You should at least be able to change the admin’s password. But really you should also be able to create logins linked to Emps, so that people could edit their own details.
  • Persistence. I really wanted to step outside the default EF Core solution that .NET Core pushes you towards. Instead, I would like to see some kind of open source document database integrated. Just haven’t gotten around to it.
  • Cloud-deploy-friendliness. It should be a breeze to deploy the app as a single unit, while still giving a clone-and-run developer experience. Possibly Docker would come in to play.

In addition, there’s a bunch of smaller to do items in the readme left. But the bottom line is: it’s not finished yet.

And that’s okay! Because I learned a lot while building it. Also, the truth is that I spent my time elsewhere past months. And that was a conscious (and wise) choice.

Still, I’m a little sad to declare EmpGrid dead before it got up and running somewhere…

Resurrection?!

So perhaps I should resurrect the project?

Well, not immediately. Or, more specifically, I will not promise that it’ll be resurrected. For one, I’m due for a long, relaxing vacation to Sri Lanka. And second, I see several other cool ventures coming up (hello Advent of Code!!). So perhaps EmpGrid will stay dead.

Or maybe I need a partner in crime?

Time will tell. For now: good bye, EmpGrid. Hibernation mode: on.

A New Hope

Jeroen

Did I mention before that I write here to collect my thoughts and as writing practice? Well, in any case, after my previous monster post, and given that it’s the start of a new year, I figured I’d do a “New Beginnings” post. Then the sci-fi addict in me awoke and typed “A New Hope“, even though I’m a Trekkie at heart. But I digress.

I wanted to summarize which technologies and experiments I’m most interested in pursuing next. Let me try to list them in order of current preference.

1. Elasticsearch …. and Nest?

Elastic as a (primary?) data store intrigues me. It feels like a second chance for Lucene towards me (experimenting with Solr didn’t “click” for me). There recently was a major version released so it seems like a great time to start investigating. I’m hesitant about Nest though, which you’d kind-of have to use if you want to access Elastic with .NET: during my first few experiments I felt like I was “wrestling” the API.

2. Gulp, or: More Gulp!

I’ve done quite some work with Gulp recently, and it was a very (and surprisingly) fun experience! In the past, most devops tasks felt like chores to me, but not so much with this Gulp. So this point would actually be “More Gulp” (as I’ve done quite a bit of it recently already), but I still have quite a list of things I want to try out, like for instance setting up JSCS.

3. Node

Yes, yes, I know: I’d be a hipster-after-the-fact if I’d start on Node now. Even so, I enjoy writing Javascript, and Node would be a way to do even more of it in my pet projects. Not sure how I would be utilizing Node yet: with ExpressJS, for custom (Gulp) packages, general scripting, or perhaps something like project Euler.

4. Linux

This one’s been on my mind for a while now: perhaps I’ve been stuck too much in my Windows-comfort-zone. It would be good to shape up my base knowledge of Linux as a development environment.

5. Grunt

Why yes, in addition to Gulp there’s also Grunt on this list. Gotta know what’s on the other side of the fence to be able to compare, right?

I’m placing a short but distinct separation here, because these are currently mostly “in reserve” kind of ideas.

6. Couchbase

Working a little with this at work as well. There’s a few things I’d be excited about to try at home, mostly features from version 3 and 4. Would need a “subject” though to make it interesting…

7. Study three-way-diff-tools

For some reason I never got my mind wrapped around these tools. And that’s frustrating. I should just spend a few hours trying to understand the details of these tools… I guess.

8. Raspberry / something IoTish

This one’s on the list because it nags me that I don’t see what all the rage with IoT is (or is it “was”?) about, and for that reason I feel like I have to “make Slackbot call a webhook that calls my webserver that calls my Raspberry which turns on a LED strip and autopilots a drone around in my room”. Or something.

9. Android app

I’m curious how the Android-dev-experience compares to my short experiments from around 2011. This would also allow me to revisit Java. But on a whole I feel I’d have to invest a lot of time or not do this one at all.

10. Closure Compiler

It’s on the list because I find the idea of it intrinsically interesting. It’s low on the list because I’m not sure if I work on things personally or professionally at the moment where this would be worth the investment.

Wow, that worked like a charm! Apologies for the stream-of-consciousness post, but now I do know what to do next! And I’m not even going back to adjust the (order of the) list accordingly, I’m just gonna leave you all hanging out there, guessing at what’s next…

Finishing TimeLine

Jeroen

Oh my, that code… where to begin!?

Before you read on, perhaps you should have a 30 sec look at what I’m talking about. I’ll wait here, go ahead!

…

Current thoughts about this project

TimeLine’s at prototype status, but hopefully it’s clear what the app was meant for: visualizing experience over time, using grouped, parallel timelines.

I look back at this mini-project, and directly notice a few things. First and foremost: I still like the idea of such an app! Visualizing work experience is great for a résumé I think, it allows the reader to instantly get a “feel” for what you’ve been working on. Much better than dreary text.

The second thing I realize is that I clearly had no idea and/or time to quickly scaffold an editor (“yes”, I thus resorted to using a textarea with JSON; so sue me!). Today I’d use KnockoutJS for this, even in a mockup. Or, barring KO, I’d use some other plugin for it. But then again: “first make it work, then make it work better”, so I’m happy I chose something and moved on.

The final thing I realized: it’s a decent prototype, and to get there I sacrificed a lot of code quality. With 140 SLOC it’s not much code, but what’s there is rather bad.

Finishing things

This leaves me a bit in a tight spot. What am I to do with this project?

First I thought about deleting the thing entirely, praying no one would ever find out about the JavaScrippaghetti I had unleashed on the world. Then again, that would be silly: everyone needs to write a fair share of bad code to get better at writing code.

My second thought was to rewrite the thing from scratch: right here, right now. Nearly started working on it too. Guess I wasn’t lying when I said I still like the idea. Then again, that would be silly: I still have two other projects left to “wrap up”, one of which is much more deserving of my time.

My third and final thought was to wrap up by doing a loose “code review” of my own code. In addition it feels good to “stamp” it with a disclaimer and message that it’s “wrapped up”. And that actually seems like the best idea.

Code review

The html is not really worth going through. It’s a plain html-reset-based file, that uses semantic markup (header, nav, article, etc), and has a placeholder div where Raphaël will draw the timelines. The html contains a link to timeline.js, and some basic bootstrapping code to call timeline jQuery-plugin-style on the placeholder div.

Let’s dive into that one code file. It’s starts off with some good signs:

Apparently the code’s being linted with a more sane version of Crockford’s jslint, and the code declares ES5 “strict mode”. Guess the author did forget to run the linter recently, because currently it seems to still cause a few errors. Anyways, moving on we see:

Not exactly globals, but a definite hint the author’s struggling with JavaScript closures. Except for paperPadding perhaps, which hints at a feature for settings that’s just not implemented yet.

Moving on the code follows a typical jQuery plugin template, first with all the plugin’s methods defined within a seperate closure, then at the end of the file exported in a typical fashion:

What you can already see here though is that the plugin relies on one single god method: init. This method in itself isn’t all too interesting. It just loops through the grouped timelines, and renders them one by one. To find some things that are of note I went through a mix of Dutch and English comments (not a good thing for something intended to be public). Here’s one that’s particularly interesting:

Phew, at least the author realized the code could not go on like this for much longer. This is further clarified by the presence of this kind of code (abbreviated):

Yikes! The break statement is IMHO often a code smell (smells of goto), surely there’s an OO-approach for the problem being solved here.

Let’s finish on a positive note though, having a look at some of the variable names in use:

  • categoryHighway
  • lane
  • segment

This makes me smile. Having the UI of the app in mind I instantly know what these mean. A segment is one piece of timeline, a lane is a horizontal area where segments can be placed, and a catgory highway is a set of lanes for segments from one category. Close-reading the code I find this is in fact mostly correct. And with that I feel there’s a great OO (or more prototypical) way to reboot the code for this app.

In Conclusion

In conclusion, or perhaps more appropriately “in summary”, I can say this is a fine and above-all inspiring prototype. The code’s short and bad, but not even that bad for a quick prototype.

With a proper disclaimer and “wrap up” message I feel can safely leave TimeLine be for now. Perhaps one day I’ll revisit it.

Finishing BattleTop

Jeroen

Okay, the title is about as uninspired as topping a vanilla ice cream dessert with chocolate sauce. But it’s to the point! Also, with slight OCD, it’s nice that my archives will show nicely aligned “Finishing …” titles. This is important for many reasons!

BattleTop ThumbnailAnyhow, as I’ve announced recently, I had already finished wrapped up one project: BattleTop. Have a peek at the Source, or check out the Live Version.

Elevator Pitch

What would’ve been the Elevator Pitch if I had made one when I started? Something like this:

I’m developing an app for keeping combat initiative so tabletop RPG groups can skip the tedious parts and share the initiative state easily, using (mobile) devices that are present in sessions anyways.

Writing elevator pitches is far from my specialty, perhaps I should’ve said something about “the competition” too: I’ve actually looked for existing apps, and tried a few from the Android Play Store. Only a few existed at the time, and they were very unsatisfactory.

What’s it built with?

I’ll be honest: from the subset of suitable technologies, I didn’t choose based on “best for the job”. Instead, I chose two technologies that I wanted to learn more about, and stayed in my comfort zone when choosing the rest.

The initial prototype was built with:

  • Html5, because at the time I loved tinkering with the new semantic tags. Also, I intended to learn all about tinker with LocalStorage for saving state between (possibly accidental) page refreshes.
  • Custom CSS, because it’s “good enough” for a prototype, and switching to SASS or LESS later on is easy.
  • jQuery, because I thought I wanted to learn how to write jQuery plugins.

Only two days / 11 commits after I had started did I branch off to rewrite things MVVM style with KnockoutJS. I’ve not looked back since. It also paved the way for easy unit testing, allowing me to experiment with QUnit.

How’s it wrapped up?

The frequency with which our group did RPG sessions had dropped dramatically. This removes the need to have a tool, the motivation to keep developing it, and the ability to test it. And this is okay with me. I learned some cool new things, and heck: it even got it to a functional beta version.

To wrap it up I just reviewed all of my code. Unit tests had already been done in August, and even though the code isn’t the fanciest ever, it didn’t have any obvious loose ends or idiotic bugs. So after some minor changes I just added a “discontinued” warning to the code, the live version, and the project site, and that’s that: closure!

Any future for BattleTop?

Not very likely. I think I prefer to focus effort on one certain other project, and after that probably even start new projects before picking up BattleTop again.

But like I said: I’m okay with that.

1995: It was a very good year…

Jeroen

Apparently, 1995 was a very good year. But wait, I get ahead of myself!

Recently I had a conversation with a friend about CMSes. We were confused, disagreeing on whether “Django” was a CMS or a web application framework. Neither of us was entirely sure, both of us being developers in the Microsoft stack.

Given that looking for (meta-)comparisons, and coming up with (sometimes far fetched or even disrespectful) parallels is a “secret” hobby of mine. So why not attempt to insult as many technology zealots in one go as I can by comparing popular technologies? At the very least I’d find out if Django is a CMS or web framework.

Turns out it is both.

Of course, finding parallels is hard and at times nearly impossible. Platforms and technologies differ and overlap at times, making a tabular comparison quite a challenge. Here’s my (first) attempt at a comparison:

Web App Framework(s) Example CMS(es) Package Manager(s) IDEs
C# (and VB.NET)

Current: 5.0
Originated: 2000
Microsoft

 ASP.NET: WebForms & MVC DotNetNuke, Orchard NuGet Visual Studio, MonoDevelop, SharpDevelop
Java

Current: 8
Originated: 1995
Oracle

 Spring, JSF, Struts, Google Web Toolkit, etc. Liferay, Hippo, Open CMS, Pulse Maven Eclipse, IntelliJ, NetBeans
PHP

Current: 5.6.0
Originated: 1995
The PHP Group

 Zend 2, CakePHP, CodeIgniter, Symfony WordPress, Drupal, Joomla! Composer PhpStorm, PHPEclipse, Zend Studio, NetBeans, Sublime Text
Ruby

Current: 2.1.2
Originated: 1995

 Ruby on Rails Radiant, Refinery, BrowserCMS RubyGems n/a
Python

Current: 3.4.1
Originated: 1991
Python Software Foundation

 Django Django-CMS, Plone Pip, PyPM n/a
JavaScript (Node)

Current: 5
Originated: 1995
Joyent

 Node.js Ghost, KeystoneJS, Hatch.js, Calipso npm n/a
Perl 5

Current: 5
Originated: 1987
The Perl Foundation

 Catalyst, Dancer, Mojolicious Bricolage nCPAN, PPM n/a

There were two main takeaways from this comparison for me. First, apparently “Django” is a Python web application framework, and “Django-CMS” is, well: a CMS. Second, 1995 was a very good year: Wikipedia lists 4 out of 7 languages as originating in 1995.

Guess it was a very good year.

70-480 (HTML5 with JavaScript and CSS3) Study Plan

Jeroen

Looking for my exam summary? Jump straight to it! Want to know more? Keep reading…

Last year I published my study plan for the 70-513 Microsoft exam (“study log” would’ve been more appropriate), which helped me pass the exam (without cheating by using brain dumps) with just under 200 hours of study time. This time I’m going for the 70-480 exam (html5, JavaScript, and css3), and I’ve decided to use an actual plan. When I started rolling up this plan, there were a few premises.

First up: the date for my exam is already set. I will probably not be able to spend a full 200 hours on the subject matter before planning my exam. The plan will have to scale with the amount of time I will turn out to have available. Anyways, given that the exam was free of charge, it’s not as big a deal if I don’t pass it.

Secondly, the subject matter for 70-480 is not entirely new to me, as was the case with the 70-513 (WCF) exam. So, my plan would be okay even if it omits more general prose about the subjects and sticks to the details of objectives. I’m not sure how this will affect my chances. I’m hoping my existing knowledge make things easier, but at the same time I’m afraid that it won’t…

Finally, and most imporantly, I figured that reviewing the exam objectives very carefully should be enough. Because the exam is brand new, there is no official study guide, nor are there any books specifically aimed at the exam. I was hoping to piggyback on someone else’s summary, but given that I couldn’t find any decent one, I decided to create my own.

The Plan

So here are the steps I’m taking to study for this exam:

  1. Create an overview of all exam objectives.
  2. Find links for all objectives (at least one, preferably two or more per objective), from various sources:
    1. The relevant spec.
    2. The W3 wiki, if applicable.
    3. MDN (my personal favorite source for most web development topics).
    4. MSDN (it’s a Microsoft exam, after all).
    5. jQuery (Microsoft’s gambling hard on this library, it seems).
    6. Miscellaneous other sources (DiveIntoHtml5, Stack Overflow, etc)
  3. Review all objectives by reading through the linked pages.

So far I’m pretty happy with the result. If you want to piggyback on my 70-480 summary: be my guest! It looks something like this:

70-480 Study Guide

Creating the list and digging up all the links took a few nights work, all done over the course of the previous two weeks. Next up: two weeks of reviewing these objectives, followed by the exam itself.

Wish me luck!

BattleTop

Jeroen

Exactly one month ago I wrote about Google Code hosting. At the time I wasn’t ready to divulge the project I was using to test it, but today’s different. Today, I have decided to put BattleTop in Beta!

BattleTop is a responsive single-page web application to assist in bookkeeping things like Characters, Initiative, Hit Points, Conditions, et cetera, during D20-based table top RPG sessions.

BattleTop Beta Logo
BattleTop Beta Logo

You can view it, clone it, and provide pull requests for it at Google Code. Mind you, it is still in beta, meaning there’s many rough edges and bugs to be found. I have been and will be dogfooding it during our own table top RPG sessions, so I’ll be sharing your frustrations about bugs and time permitting I will be fixing things.

The current list of features:

  • Track characters. Add and remove monsters, NPCs, PCs, and environment initiatives. You can also reset the list to the party, or to a blank, new list.
  • Track initiative. Keep initiative and initiative modifiers, sort the list by initiative, keep track of ready and delay actions.
  • Track conditions. Each character has its own list of conditions which you can add, remove or change, with a number of turns to it (so they wear off automatically).
  • Track hit points. Each character optionally has a number of hit points. You can deal damage or apply healing to change the hit point amount.
  • Save/Load. Using the LocalStorage API BattleTop will save your state every 5 seconds. If you navigate away or re-open the page on your next play session the old state will be there.

Note: because BattleTop extensively uses many modern features (html5 semantic markup, css3 features, modern JS such as LocalStorage), only modern browsers will be supported.

Here’s a general view of what it currently looks like:

 

BattleTop 0.9.0 Setup Mode
BattleTop 0.9.0 Setup Mode

 

BattleTop 0.9.0 Update Hit Points
BattleTop 0.9.0 Update Hit Points

The horrifying state of free Android initiative-keeping apps was what triggered me to create BattleTop. I’ve decided on a HTML5 app as opposed to a native app because (a) it would be easier for me to create something in a short amount of time, and (b) to keep it portable across devices and operating systems with little effort. Hopefully BattleTop will help or inspire others as well.

CSS syntax naming conventions

Jeroen 2 Comments

My next Stack Exchange Challenge post will most likely be about the Programmers SE. One part of the challenge is to actually ask a question I have on the topic. The question I came up with (to be honest, this has been bothering me for months now) took quite some time to write down carefully. So, as I don’t have my next SE Challenge post ready yet, I decided to cross-post my question here on my blog as well.

The Question: what are the practical considerations for the syntax in class and id values?

Note that I’m not asking about the semantics, i.e. the actual words that are being used, as for example described in this blogpost. There are a lot of resources on that side of naming conventions already, in fact obscuring my search for practical information on the various syntactical bits: casing, use of interpunction (specifically the - dash), specific characters to use or avoid, etc.

To sum up the reasons I’m asking this question:

  • The naming restrictions on id and class don’t naturally lead to any conventions
  • The abundance of resources on the semantic side of naming conventions obscure searches on the syntactic considerations
  • I couldn’t find any authorative source on this
  • There wasn’t any question on SE Programmers yet on this topic

Some of the conventions I’ve considered using:

CSS naming conventions
CSS naming conventions
  1. UpperCamelCase, mainly as a cross-over habit from server side coding
  2. lowerCamelCase, for consistency with JavaScript naming conventions
  3. css-style-classes, which is consistent with naming of css properties (but can be annoying when Ctrl+Shift+ArrowKey selection of text)
  4. with_under_scores, which I personally haven’t seen used much
  5. alllowercase, simple to remember but can be hard to read for longer names
  6. UPPERCASEFTW, as a great way to annoy your fellow programmers (perhaps combined with option 4 for readability)

And probably I’ve left out some important options or combinations as well. So: what considerations are there for naming conventions, and to which convention do they lead?

Re-discovering JavaScript

Jeroen

Around 1995 I started creating web pages. HTML was my friend, and analogous to the story of Adam and Eve, a companion called CSS was created. I considered HTML to be the robust male of the relationship, and CSS giving the beautiful female touch to my web pages.

Then Darkness came.

A brand new player invaded my perfect little web world and tried to make it into a love triangle. Enter JavaScript. At first this new technique looked awesome to me. I knew Turbo C++ 3.0  (with a nice DOS look and feel) as well as Visual Basic, and was eager to add some dynamic features to my web pages.

Oh how I underestimated the complexity. I knew no patterns, none of my code had ever been reviewed by others, and I tried to figure out everything with trial and error. Plus: I didn’t understand the DOM at all. So I ended up writing stuff like this:

The above snippet must have cost me a week to figure out. I was so frustrated I wanted to ban JavaScript from my pages as much as possible, which is exactly what I did when I learned to use Perl to add dynamic features to web sites.

More than a decade passed, but Darkness was still looming. I tried to stay in the Light with my happy couple HTML and CSS (only tolerating incidental guest appearances by JavaScript). I even turned to WinForms programming in .NET so I wouldn’t have to face the Darkness.

But then my ASP.NET days came, and it turned out: JavaScript was here to stay. However, my second encounter with JavaScript was mediated by jQuery, which had powers rivaling those of Dr. Phil himself. That library makes JavaScript feel like the love child of HTML and CSS, with a dynamic twist.

And so, JavaScript is getting a second chance. Any leftover JavaScript frustrations were explained in this presentation: I started to use JavaScript without ever learning it. So I picked up the corresponding book by Douglas Crockford, which shall be followed by The Definitive Guide. Hopefully this will allow me to Learn to Stop Worrying and Love the Bomb.

Foot note: at the time of writing, the piece of JavaScript code in this post is still running in production, in a Web Shop created in the 90’s, using Perl 5, HTML4, CSS2, and a hint of JavaScript…