Category Archives: Uncategorized

PanelMatic 101 (Reprint)

Long long time ago, I can still remember, how I used to do Java Swing applications for living. Swing has a lot of strong points, and I really admire its design and architecture. When one needs to make a desktop application in Java, it still rocks. Of course, Swing is not bereft of annoyances. One of these is creating panels with complex layouts.

To my pleasant surprise, I had some Swing-related projects recently. So I revived an old open-source library of mine, which was originally hosted on Kenai.com (yes, that was that long ago). It was called “PanelMatic”, and it enjoyed a mild success back then.

So, PanelMatic is back. It’s using Java 11, it’s on GitHub, and it’s on its way to Maven Central. Below is an slightly modified intro that was published originally at Java.net (yes, that was that long ago).


PanelMatic 101

Every Swing developer knows this feeling: you’ve got the design of a UI panel. It’s the ‘right’ design. It ‘works’. It’s what the user would expect. Hell, it’s even what you would expect had you been the user. But it is going to be an awful lotta’ coding to lay it out in Swing – even before you take into consideration issue like panel re-sizing and localization.

Some developers nest numerous panels to get it working. Some try to “fake it” using the null layout (please, don’t). Others try to fit everything into a single panel and use the GridBagLayout – this involves quite a bit of trial-and-error, as can be seen in this documentary. Some even turn to graphical UI builders, which does not support dynamic panel creation, and whose designs are hard to maintain.

I’d like to suggest a slightly better solution: PanelMatic.

Figure1: Sketch => Code => GUI

PanelMatic allows swing developers to create common UI panels with ease. Panels are built top-to-bottom (or, more precisely, on the page axis). There is an intuitive connection between the way the code looks and the way the created panel will look. Components can be added to the panel with a label and/or an icon (lines 3-7 in Figure 1), or alone (line 9). By default components stretch to occupy all the space they get, but this can be changed using modifiers (lines 9, 10). L_END (stands for “line end”) and GROW (stands for “grow”) are statically imported constants, and are in fact full-blown objects that implement the BehaviorModifier interface – so you can create your own modifiers if you need ’em. Client code can add headers (lines 2, 8) and flexible spaces (not shown). The default implementation uses a pluggable component factory to create all the extra components involved (e.g. JLabels), so you can customize them when the defaults won’t do.

As you’ve probably guessed, panels are built by builders that are obtained by invoking a static method on the PanelMatic class. PanelMatic is designed around an API/SPI approach – all the client code gets to hold is an interface, so the implementation can be changed without affecting client code at all. Builders are pooled, so you don’t have to think twice before asking for one. You can create your own implementation – just implement the service provider interfaces, and point the PanelMatic class to it. This can be done either by code or via a system property.

So this is PanelMatic. Use it to create common UI panels quickly, and use your freed up time to go to more meetings and catch up on some quality powerpoint presentations.

We could stop here, but we’d be missing half the fun.

Beyond Layout

PanelMatic’s approach to building UI panels allows for some surprising improvements over normal layout-based code. Here are some of my favorites.

Customizers, or Listening to All Components

Components are passed to the builder, and eventually get added to the produced panel. But before they are, they pass through a chain of PanelMaticComponentCustomizers, or “customizers”, for short. Each builder has two customizer chains – one that applies to all the panels it builds, and one for the current panel being built. The latter is disposed after the get() method is called. Customizers have a customize method, which gets an returns a JComponent. This allows client code to apply uniform customizations to all components in the created panel, or in the application in general. These customizations can be used for, e.g:

  • Changing the background of the focused component
  • Automatically wrap Scrollables in a JScrollPane
  • Listen to all components in a panel

Let’s look into the latter example. A very common requirement is to have a “save” button enabled if and only if the user changed some data on the screen. This involves listening to all components the user can interact with. Normally, this requires a lot of boilerplate code. Instead, we can create a customizer that adds a change listener to every component added to the panel, and then add a single listener to that customizer. Incidentally, PanelMatic comes with such a customizer out of the box:



ChangeDetectorCustomizer cdc = new ChangeDetectorCustomizer();
panel = PanelMatic.begin( cdc )
	.addHeader( H1, "Song Details")
	.add("Name", txfName)
	.add("Album",txfAlbum)
	.add("Artist",txfArtist)
	...
	.add( btnSave, L_END)
	.get();

cdc.addListener( new ChangeDetectorCustomizer.Listener() {
	@Override
	public void changeMade(ChangeDetectorCustomizer cdc, Object o) {
		btnSave.setEnabled(true);
}});

The ChangeDetectorCustomizer adds the appropriate listeners to all common swing components, so any change made to any component makes the save button enabled. It also recurses down the containment hierarchy, so changes made to JCheckboxes nested in some sub-sub-sub-panel are detected as well.

Localizations

PanelMatic’s PanelBuilders can pass the labeling strings “as-is”, like we’ve seen so far, or use them as keys of a ResourceBundle. Resource bundles are set using static methods of the PanelMatic class itself, and affect all builders generated afterwards. The same goes for ComponentOrientation. So it takes only two lines of code to move from an English left-to-rigth UI to a right-to-left UI in Urdu/Hebrew/Arabic or any of the other RTL languages. That, and someone to translate the texts.

Figure 2: Localizations can be easy (as long as you have someone that can write the texts in the target language)

Building GUI Using Expressions – Anonymous Panels

PanelMatic allows panels to be created and laid out using a single expression. This is contrary to the normal UI construction process, where one first creates the panel, then applies a layout, and then adds sub-components – each in a statement of its own. The problem with statements is that they cannot be combined – they just sit there, one after the other, as if in a shopping list.

Expressions, on the other hand, can be nested and composed with other expressions. They are “first class citizens” in java, and can appear anywhere. So, one can create a sub panel while adding it to a bigger component:

JTabbedPane tabs = new JTabbedPane();
tabs.add( "Tab 1", PanelMatic.begin()
	.addHeader(HeaderLevel.H1, "Tab 1")
	.add("User Name", txfUserName )
	.add("Password", txfPassword )
	...
	.get());

This is somewhat similar to Anonymous Classes (those are the classes with no names that are created, say, when you implement an ActionListener). As anonymous panels can go anywhere, the below code works:

System.out.println("A panel with two JLabels would "
	+ "have a preferred height of "
	+ PanelMatic.begin()
		.add( new JLabel("Label 1"))
		.add( new JLabel("Label 2"))
	    .get().getPreferredSize().height + " pixels.");

On my mac, it says:

A panel with two JLabels would have a preferred height of 40 pixels.

Advanced Customizations

PanelMatic takes the “convention over configuration” approach. Everything can be customized, but you normally don’t need to bother with it. When you do, there are several levels of customizations available: one could subclass a PanelBuilderFactory (easy) or implement the entire stack (builders and factories) or get to some level in between. The exact details are beyond the scope of this article. Bottom line – as long as you can build your panel along the PAGE_AXIS, you can customize PanelMatic to build them. The client code should not be affected when you switch from the default implementation to yours.

Wrapping up

PanelMatic is a small library that allows swing developers to quickly create common UI panels. It helps with localizations and customizations and makes the code creating the UI readable and intuitive. It’s easy to pick up and hard to put down, though I might be slightly biased. Why not give it a go and see for yourself?


https://github.com/codeworth-gh/PanelMatic


Maven: Local is the New Remote

Often I stumble into a case where I need to use Maven, but also use specific, non-published .jar files. In Ant’s world, you’d just throw these in a local directory in the project’s dir. That would be simple. Handling the transitive dependencies of the rest of the jars would not be. Which is why Maven rocks and we should all be using it.

But then there are the local-only jars.

So here is the solution I ended up using: have a local repository in the project’s directory, and deploy the jars there. This way, that repository can go into your version control system (i.e. git repo) and you can use Maven normally. Here’s how it’s done.

a) Create local repository. This is easy, just make a directory, and call it “lib” or something.

b) Register the repository in your pom.xml. Like so:

<repositories>
  <repository>
    <id>project.local</id>
    <name>project</name>
    <url>file:${project.basedir}/lib</url>
  </repository>
</repositories>

c) Add a jar to that repo. This is done from the commandline, using mvn:deploy-file command:

mvn deploy:deploy-file \
-Dfile=/path/to/jarfile.jar  \
-Durl=file:///path/to/the/project/lib/ \
-DgroupId=somegroupname \
-DartifactId=artifactname \
-Dversion=0.9 \
-Dpackaging=jar \

Clarifications:

  1. backslashes (“\”) are for escaping new lines, so the command is easier to read. They can be omitted, along with the newlines (“\n”s).
  2. version 0.9 is as made up as the group name and the artifact id.

d) Use your jar the Maven way by adding it as a dependency

<dependencies>
     <dependency>
         <groupId>somegroupname</groupId>
         <artifactId>artifactname</artifactId>
         <version>0.9</version>
     </dependency>
    ... regular dependencies ...
</dependencies>

That’s it! Pretty simple, and now that I’ve finally written it down, I won’t have to search for this solution over and overt again. Hopefully.


PSPS

At CodeWorth.io we create many web applications. Unless there’s a very compelling reason not to, we’re using the Scala flavor of Play Framework, which we find performant, fun to work with, and generally easy to maintain (static typing FTW! There. I’ve said it.).

Now, Play is a very non-opinionated framework that’s happy to work with multiple database servers, front-end kits, etc. It’s great since it provides us with the flexibility a software studio like us needs. On the flip side, though, we found ourselves re-implementing various functionalities, such as nav-bars, page layouts, and logins (including “forgot password” flow and such). The textbooks say that re-implementing functionality is wrong. That’s only partially right – when you implement a functionality for the fourth time, you’re doing a much better job at it. But enough is enough – one would also like to write some new functionality from time to time.

Enter PSPS. This is a very opinionated application seed. We built it by collecting our best implementations, and then cleaning and brushing them up one more last final time (hmm, actually, we could improve this a bit by…) . PSPS is based on technologies we found to be reliable, and easy to work with and extend. Nothing fancy or surprising, really: PostgreSQL, Bootstrap4, and Slick.

Out of its proverbial box, PSPS supports many features common to web applications:

  • User management
  • Public and user-only sections
  • Navigation bars (including menus, and created using type-safe Scala code)
  • Database connectivity
  • UI Components and functionality (paging, page headers, buttons, JS alerts…)
  • Page templates that support localization, CSRF, informationals, etc.
  • Basic localization
  • Ajax functionality (wrapping Play’s JS Routers)
  • Scripts for deploying on UNIX boxes
  • Documentation (yay AsciiDoc and antora)

We have been testing PSPS internally for a while now, and believe it’s ready human consumption. It might even be good for said human, e.g. if they’re a part of the Play Framework community.

So feel free to try it out – it’s open sourced under Apache v2.0. We’re happily accepting improvements, suggestions, and pull-requests. Hopefully, together we can get the Play community an excellent application seed, so we can all focus on writing new things.

I can’t forget what you did last bp.sync

An evening of hunting memory leaks

‘Twas a lovely early afternoon in the Be’er-Sheva campus of Ben-Gurion University, when AS mentioned that a system based on BPjs is slowing down after running for about ten minutes. I’m generally happy when I get bug reports (it means that people use the software), but this reports sounded like it might be an issue that could be caused by something that may or may not – but quite probably may – be a memory leak.

I don’t like memory leaks. They can be pretty hard to nail down.

We opened JConsole to sample the suspected running JVM, and looked at the memory usage graph for a while. It did go down when the GC kicked in, but never quite to the level it was before. I was toying with the hope that a major GC would kick in an get us back to a civilized level of memory consumption, but for no avail. We were, indeed, looking at a memory leak.

I don’t like memory leaks. They can be pretty hard to nail down. And have a tendency to appear when one needs to write two papers and a PhD thesis.

There was one hope, though – it could be a leak in the using system, and not in BPjs. To find that, we created a simple b-program that waits for external tick events, and then toggles a virtual switch. The program used a static set of a few events (the “new” keyword was never used).

This time, looking at the JVM using Java Mission Control (JMC), there was no doubt:

Where did 119820 extra BEvent instances come from?!

Memory consumptions didn’t look to good either:

After the usual start-up mess, the familiar saw-tooth graph slowly creeping upwards appears. Yep, that’s a memory leak, and in BPjs.

I hate memory leaks. The good news where that I didn’t have any plans for the evening.

We did some extra tests, and noticed that when we release a BProgramRunner instance, the leaked memory is freed. I’ll have to start there.

Seek-a-Leak

The main issue with memory leaks – you need to understand your system in all its levels. Every method and value are suspects. I once hunted a leak in a Java (1.4.2) Swing application, and it turned out that hiding the caret in a JTextPane prior to displaying the JFrame containing it leaked the entire window through references left in the timer mechanism that was responsible for blinking the caret. I chased references using an Eclipse debugger and a block of paper for a three whole days to prove that.

Even more annoying, that bug was already reported when I realized what was going on.

Luckily, BPjs is much smaller than the Java standard library – about 4600 lines. But it relies on Mozilla Rhino, which is also a suspect.

I started from BProgramRunner, and traced all references it had. The JMC report showed that the sync statements and BEvent counts were in the 100Ks, so that had to do something with the runtime of the JavaScript code itself. My hopes for some classroom example of a map somewhere caching instances were gone.

The good news where that I didn’t have any plans for the night, either.

Scopes and Proxies

I was poking around the code drawing blanks, so I started doing some clean-ups and solving old issues, trying to come up with something. Issue #32 caught my eye – I wanted to get rid of the BThreadJsProxy class, but never got around to doing it. OK, issue #32 it is.

At the beginning of BPjs, b-thread could call “bsync” to synchronize with their peers. That method was implemented in BThreadJsProxy, a class whose instances were made available to the JavaScript client code by placing them as a scope in the scope hierarchy under which the JavaScript code runs. Later, other runtime features found their way to this class.

As the BPjs library evolved, we moved everything BP to a “bp” object that BPjs made available to the b-program code in a similar way. That bp object, implemented by BProgramJsProxy, is b-program global, and is not aware of any specific b-threads. The only BPjs runtime feature that required a specific b-thread is the ability to set interrupt handlers. Boilerplate aside, that was the only method left in BThreadJsProxy. Moving it to BProgramJsProxy is non-trivial and seemed unimportant at the time, so this class stayed. With nothing better to do, I’ve moved the interrupt handler mechanism to BProgramJsProxy, thanking whoever decided to add ThreadLocal to Java’s standard library. That’s it – BThreadJsProxy can be removed. The leak stays, but at least #32 would be solved, so the evening won’t be a complete waste of time.

I started removing references to BThreadJsProxy from the runtime and analysis sub systems, when I encountered the code where I’m placing the proxy in a scope, so that the JavaScript code can call it:

    void setupScope(Scriptable programScope) {
Scriptable bthreadProxyScope = (Scriptable) Context.javaToJS(proxy, programScope);
bthreadProxyScope.delete("equals");
<more deletes>

bthreadProxyScope.setParentScope(programScope);
// setup entryPoint's scope s.t. it knows our proxy
Scriptable penultimateEntryPointScope = ScriptableUtils.getPenultiamteParent(entryPoint);
penultimateEntryPointScope.setParentScope(bthreadProxyScope);
scope = entryPoint;
}

I was quite proud of this code when I wrote it – I rarely get a legitimate excuse for using the word “penultimate” in a variable name. But since everyone are suspects now, I looked closer. This code adds another scope to the scope hierarchy within which the JavaScript code runs. That’s cool. The not-so-cool part, is that it runs each time a “sync” is called. So, each time a “sync” is called, another scope is added to the hierarchy, caching things like BEvents. And, effectively, causing a memory leak.

I hate memory leaks.

Removing the BThreadJsProxy class was one of those nice refactors where you delete more than you add. It also solved the leak:

The memory itself also looks better now. After the initial startup mess, the same program occupies less than 32 MiB consistently:


Takeaways

  1. Love thy early adopter. And be prepared to get some serious bug reports when a framework starts to get traction.
  2. Mozilla Rhino is pretty performant even when one uses it badly – that leak was there for a while, and nobody noticed until the system was used to execute long-running tasks for a long time.
  3. Profiling and inspection tools like JMC and JConsole rock.
  4. Don’t leave design related fixes laying around for too long.
  5. Don’t make plans for the evening – you can never tell whether you’ll have to deal with a memory leak.

The Curious Case of the Maze Walker and the Cow’s Tail

The Backslash Incident

I guess it’s never a good time to find out your code has bugs. But there are exceptionally bad times to do so. A middle of a live demo is one such example. Immediately after said demo, when you’ve invited the attendees to take your code for a spin, is not too good either.

Case in point: I had the honor of presenting BPjs at a seminar at Harvard School of Engineering and Applied Sciences (SEAS). BPjs is a tool suite for running and verifying programs written in JavaScript, using the Behavioral Programming programming paradigm. In short (very very very short): It’s a paradigm that focuses on how the system should behave, rather than on how its implemented (e.g. objects, functions, or procedures). Because behavioral programs (“b-programs” for short) can be verified against a set of formal specification, BPjs allows writing verified systems in JavaScript. Which is, admittedly, weird. But in a good way.

As part of the above mentioned demo, I’ve created VisualRunningExamples, an application that allows playing with a behavioral program for a maze walker. Users can load and modify the walker’s behavioral model and formal specification, and then run or verify it, using a friendly GUI. It also serves as an example of how to build a program around a BPjs model.

VisualRunningExamples – Maze solution obtained by formal verification of the maze and walker model.

One fun part of VisualRunningExample’s UI is the selection of the maze the walker would roam in. My favorite maze has a cow (created using cowsay, of course). During the presentation I let the walker walk around the cow a bit, and I thought I saw it demonstrating a bad behavior – it seemed like it was going through a wall. I’m not an expert in maze walking, but I assume maze walkers should not do that.

Immediately after the presentation, I looked into this in more depth. It seemed like the walker was moving diagonally. Which it should never do, since no part of the program requests such a move. It ostensibly went from point X to point Y:

_______
<BP(moo) >     @@@@@@@@@   t
-------
        \Y  ^__^    @@@@@@@@
@ @@@@@ X\  (oo)_______
s           (__)~~~~~~~)\/\
@ @@@@@        ||----w~|
               ||     ||

Was this really happening? Using VisualRunningExamples, I’ve added the following b-threads, and verified the program against it. The idea behind this code is that whenever the maze walker gets into a cell, a set of b-threads that look for diagonal entries is spawned. These b-threads blow the program up if they detect a diagonal mode. Pretty neat pattern, I think (reminiscent of LSC’s symbolic charts used to forbid events):

bp.registerBThread("no-diagonal", function(){
    while (true) {
      var crd=getCoords(bp.sync({waitFor:anyEntrance}).name);
    	noEntryNextMove(crd.col-1, crd.row-1);
    	noEntryNextMove(crd.col-1, crd.row+1);
    	noEntryNextMove(crd.col+1, crd.row-1);
    	noEntryNextMove(crd.col+1, crd.row-+1);
    }
});
 
function noEntryNextMove(col, row){
    bp.registerBThread("nenv(" + col + "," + row + ")", function(){
        var evt = bp.sync({waitFor:anyEntrance});
        var newCoords = getCoords(evt.name);
        bp.ASSERT( newCoords.col !== col || newCoords.row !== row, "Diagonal Movement detected");
    });
}

Verification did not find anything wrong, yet that parallel movement is happening, live, in front of my eyes. So, verification is broken too. Highly embarrassing, given that I just presented the tools at Harvard SEAS’ SPYS group. Time to do some runtime verification.

Runtime verification really boils down to adding these b-threads to the b-program (“model”), and running it. Easily done, and we know the runtime works. So, yay, next time mr. maze walker wants to do a diagonal jump, one of these b-threads will catch it red-handed. With an evil grin, I click the Run button.

Nothing. The walker does diagonal jumps like a boss. But only between points X and Y. Luckily, VisualRunningExamples’s UI is fun to play with, so I change the \ to *.

No more parallel jumps, which never really happened. Good news: BPjs’ verification works. As does its runtime.

What Went Wrong

What really happened was that when creating the source Javascript b-program, the Java layer was copying the maze into an array of strings, verbatim. This meant that \ was really an escaped space, which translates to a single space in JavaScript:

jjs$ var s = "\ "
jjs$ "|" + s + "|"
| |
jjs$

The Java UI, on the other hand, displayed the backslash in the maze monitor table. In short: the JavaScript b-program saw a space there, whereas Java saw a backslash. The ostensible diagonal jumps were just the maze walker going from X to Y through an empty cell, that was marked by the Java layer as a \ cell.

Lessons Learned

  • Need to be careful when constructing code from user input (OK, that’s not a very new lesson, more of a reminder really. But still).
  • If you have a suspicion something is wrong in a b-program, BPjs makes it easy to verify.
  • Tooling and UI that make the b-program easy to play with are very important. All in all, I went from having a suspicion to verifying the code in about an hour of casual coding on the couches at an empty student center somewhere in the Harvard campus.
  • Since BPjs uses the same structures for verification and for modeling/execution (namely, b-threads written in JavaScript), it is trivial to share code between the b-program and its formal specification. That’s important, e.g., when one wants to extract data from strings.

My experience with this whole BPjs as a verification platform, is that it enables “casual verification” – it is very easy to create and run verification code, all the tools are there already, and you’re probably in the mindset as well. Compared to re-creating the system by modeling it in, say, PROMELA, it’s much more casual. Not to mention translation errors between model and actual software.

VisualRunningExamples now has a shiny new cow that does not contain any backslashes. I kept the old cow too, but it’s now called “cow (bad)”. Escaping the maze text properly is followed by issue #1.

My NetBeans Favorite Five

NetBeans 8.2 is out, multiple cursors and all, so it’s a fitting occasion to post my five favorite features. First, some background to avoid making a just-downloaded-an-went-a-bloggin’ impression: I’ve been working daily with NetBeans since version 6 (so this post has been brewing for a while). I mostly work with Java (core, Java EE and some Swing) and with HTML/Javascript. I’ve also used NetBeans for Markdown, Scala, PlantUml, Sphinx, Python, Ruby, and making coffee. OK, forget the Ruby part.

When joining the data science team at the Institute of Quantitative Social Science at Harvard, I was happy to see they were using NetBeans as well. Dataverse, our institutional data repository system, is based on Java EE and is developed with NetBeans. It’s currently more than 97K lines of open-source code*. So you can see I have some milage using this tool.

BTW, I’ve worked with the common alternatives (both paid and free) but somehow I always come back to NetBeans. I guess I just don’t like my code being eclipsed.

OK, OK, no need to throw a BadPunException. Let’s get to it:

Little Comforts/Going the Extra Mile

Such as the suggested variable names, auto-pasting traces to the stack trace analyzer, the fact that the stack trace analyzer exists, “view differences” in the Unit testing result pane, get + code-completion generates the proper getter (there’s also a setter, of course).
And then there are the top-of-block popup and the file-too-long label. Love these.

top-of-block extended-label

Additionally, NetBeans includes the required stuff out of the proverbial box. JUnit, Git etc. No need to install manually and decide between various conflicting versions of third party plugins.

Project Groups

Switch quickly between groups of projects. Or, really, working contexts. Since I have a few separate contexts I’m working on in parallel, this feature is a huge timesaver.

Great Java (+EE) and Javascript Support

Great language support for Java (including the next version). Very good Javascript support as well. The code warnings are useful, and the “convert to functional operation” refactoring had taught me some new Java 8 features I was not aware of.

Good support for Java EE features, such as integration and plugins (JPQ modeler etc.). Integration with application servers etc. is easy. There’s also Docker integration, I hear. I’m not using Docker currently. I hope I can still keep my developer license.

Not reinventing the wheel

For example, using Apace ant at the core of the native project type make these projects useful outside of NetBeans too (an anti-vendor-lock-in vendor!).

It Just Works

It does. Srsly. It’s a very dependable tool. And I’m looking forward to seeing it graduating from its Apache incubator.

 

 

*  Count generated using David A. Wheeler’s ‘SLOCCount’.

Lessons learned by a frugal hacktivist

There’s a compulsory biometric database being built in Israel. It’s bad, but it’s not the point of this post. I’m taking part in some civilian effort to stop it, and part of this is having a website. So we built one. For free. Here it is. And here is what I learned, divided to non-technical and rather technical points.

Non-technical:

  • We wanted a good looking, fast website. As the government employes paid commenters, we didn’t want any talkback options.
  • We have some people that can build websites (me, but not just me). However, we’re all busy.
  • The website had to be updated periodically, but not too often.
  • We are a voluntary organization, and we don’t have any money.

While we were aware of standard options, such as opening a wordpress blog or a Facebook page, we decided to go with a static web site, hosted as a github project page. The motivation was that this would generate a very fast website, and we could get all the design flexibility we need (canned solutions are not that flexible, really).

However, keep in mind that github project pages come with some strings attached. The website has to be open-source, or pay for the hosting, and no server-side processing can occur. This means any updates to the site require some technical skills.

For hacktivism, the open source string may be a real issue. If you spend a lot of time creating a web site, and you don’t want the other side to just fork it and create their own version. You may want to keep your source closed. We didn’t have this issue, as the biometric database already has web presence, as well as TV commercials, posters, etc.

So far, which is not very far really, the choice for static website seems good. Here are the technicalities. The main goal was to get something done fast, but at a high quality.

Site generator

We went with harp.js. While jekyll looks like a more natural choice for github, it is not as flexible as harp. Jekyll assume you are writing a blog. Harp has a more holistic approach, and also supports lesscss (and many other languages). I already had experience with jekyll (earned while doing this site) but decided to try harp and have jekyll as a “plan b”. All in all this worked.

Front end

Bootstrap3. You can’t beat the king.

Content Generation

Here’s where Jekyll is better than Harp – we wanted to generate a list of links, display a list of them and give each one a page. Jekyll would have done this out of the box, if we would have treated each link as a post. Harp requires having a file for each page in the site, which meant we had to maintain the json map and a set of files, and make sure each key in the map has a file named after it. Not fun and error prone. Well, bash to the rescue:


cat _data.json | jq keys | grep \\w | cut -d\" -f2 | xargs -I{} touch {}.md

This line ensures that each key has a file with corresponding name. If the file already exists, it is not overridden, which is important if someone wanted to add additional data to the to a link’s page.

Issues

  • Contact forms require a back-end to process the input, and static sites don’t have any back-end. There are ways of doing them, e.g. using google forms. We address this soon, but currently we’re happy to use github issues, which also works. Also, you can use a mailto link, but you’ll be facing another set of issues there.
  • As always, collaborating using github is a pleasure.
  • When other people fork your site, they shouldn’t call their branch “gh-pages” – it makes the CNAME files collide. Only have a single branch with this name.

Conclusion

When needing a website that does not take data from users, static websites may be a good choice. If you can keep your source open, hosting them as github project pages is a fast solution that’s free and easy, as long as you have people with technical skills available. If you have some cause you’re trying to push, you can fork us on gihub.

Oh, and if you want to learn about the biometric data base in Israel and you don’t read Hebrew – we have a site for this.

Draw More, Work Less

Below are the slides for a talk I gave at IQSS about software tools that generate diagrams. Two examples are shown – GraphViz and PlantUML.
I was hoping to show that focusing on the semantic level of the diagram (e.g. structure, relations) and letting the computer decide on the actual layout can make life easier. I know I use these tool quite often.

Anyway, the slides are below. The files for most diagrams can be found here.

Geek Dad #12FFA: Cowsay

The summer vacation is upon us, and with it, the need for kids to not be bored (or is it the need for the parents to have kids that are not bored?). Coloring pictures is a nice pastime, and you can always find a lot of coloring images by going to google images and limiting the search to line art only.

But, does it educate your kids to be better geeks? Does it tickle their imagination? Not really, no. Well, what is a geek dad to do?

 _________________________ 
< Lets color ascii art!!  >
 ------------------------- 
        \   ^__^
         \  (oo)\_______
            (__)\       )\/\
                ||----w |
                ||     ||

Cowsay is a lovely little program written by Tony Monroe. It allows you to quickly create ascii art of cows saying things. And it’s not limited to cows, there is also tux, a bunny, a koala and various other images, which can be listed with cowsay --list. Do not pipe the --list result to a loop and create all the images, as some are NSFW, (or, NSFK, in this case).
Also, it’s not limited to saying things either: there’s also cowthink.

And thus:
10 Kid: Dad, can I color a cow?
20 Dad: cowsay please color me\! | lpr
30 Kid: <coloring happily>
40 GOTO 10

cowsay is available for most platforms. On linux it’s available through the package manager. On OS X, it’s available through brew.