JSP: Passing Variable Data to JavaScript

When you try to marry old JSP Technology with the modern wonders of Typescript/ES6.
You will want to expose some data provided by the backend into the Javascript.

If you have the possibility you would use a fetch() call to receive JSON.
Sometimes, it is not possible to do a big rewrite of the jsp to fix a minor bug.
Here is a very dirty way to pass data from the JSP into the JS code. This code will utilise the HTML5 data-attribute.
Learn more about it here

JSP File:



This is a very elegant solution, now you can run ESLint on your Javascript Code and will not have any unresolved variables.

Udacity – Web Tooling and Automatisation

I recently took a look at the course materials for Web Tooling and Automatisation.

Overall the course is very well structured and introduces Gulp and a couple of common packages used in webdevelopment. Besides their main topic, they cover topics on good engineering practices, like linting and testing to ensure code quality.

While working on the project I ran into several little smaller things that were quite annoying. Thankfully the gulp community is quite big, so somebody already solved some of the issues I was facing.

Passing an “--production” flag

When developing, you will probably create a version of your software that is suited for easily finding bugs and errors and an optimized version that is minified and optimized for optimal performance for the end user.

You would define two different tasks in gulp, one “default” and one “production” task. This however would in turn cause you to have to duplicate your code – with optimization and without.

I found the package “gulp-if” that allows you to control if a function like compression is active during the task.
The remaining issue was to actually set the parameter before the tasks run. (All tasks in gulp run in parallel).

To get a flag from the command line, you can use the process.argv Array. However you must add “–” before your flag name. If not gulp will assume it is another task name that should run.

In the end you would use something like this:

Note: In Gulp 4, you can use a sequencer and would not need to pass in the flag by command-line, but you would define a task that will run before all the other tasks.

Dealing with Asset sources and destinations

When using gulp.src() and gulp.dest(), typically people use strings to define the locations. However this is quite annoying if you want to get a quick overview which locations are used. For a better maintainability you should create a small variable block that defines these strings. In the long run it lets you be more flexible where your files are etc.

End Result

At the end of the course I ended up with this gulpfile.js. It adds support for Typescript, Pug(Jade), google-closure-compiler.

The common gulp tasks to run are:
* gulp serve: Uses browser-sync with css injection for live-editing
* gulp --production: Creates an optimized build

Next steps:
Depending on your webserver, you would want to add a gulp deploy task.



NPM: Use Github Patch Instead of Repository

Recently I was playing around with the HEXO static site generator.
For my setup I was using Hexo in combination with Gitlab CI and the ftp deploy method.

The module hexo-deployer-ftpsync has an issue that you need to manually confirm that the ftp deployment succeded.
In essence it does not exit on its own, thus a CI environment would not be able to automatically verify the success or failure of the build, it would just run forever.

Github allows you to fork existing code, improve upon it and issue a pull request, that your code will be integrated into the main software build.
I changed a couple of lines to ensure that the ftp deploy process would terminate.

To use my patch instead of the current master build of the module you need to adjust the package.json file.
Simply replace the version-number with the github url <username/project>#

Original: With Version Number

New: With github path to patch

If the owner of the project integrates my suggestion on how to fix the bug, then the line can be changed back to the offical master branch of the code.
However for the time being, gitlab CI uses the alternative code and successfully deploys my code to the server.

Continuous Integration (CI) for Gitbook using Gitlab and Gulp

Gitbook is a static site generator, that converts a collection of Markdown files into a HTML Site. Alternatively it can also convert the markdown files into a PDF or ebook.
If you are not writing a book, it is also a great tool to create a quick documentation for a project you are working on.

Initial set up

We will need gitbook. Gitbook does not automatically generate a file, however there is an existing gitbook-summary tool to take care of that.

Gulp will be our taskrunner.

I will deploy to my server via FTP. Since you are only serving HTML Files, there is usually no need for server restart etc.
To integreate it into Gulp I will be using vinyl-ftp.


Create a file called gulpfile.js and define your gulp tasks.

You should test especially the “deploy” task locally if everything is working correctly.

Gitlab CI Integration

You need to create a YAML File called .gitlab-ci.yml. Gitlab will recognise the file and run the commands in it.

That’s it. If you push something into the master branch, it will automatically run the commands in the yaml file and deploy your static website to your server.
When the build completes, you will recieve an email, telling you if everything went as planned.

CodeWars Kata: File Path Operations

The quick Code Wars Kata I am taking a look at the Kata File-Path-Operations.

My approach to solving the kata was, first to figure out what skills are needed to solve the problem. Since all three problems are similar and try to find a specific pattern in a string, the obvious answer is: Regular Expressions.

The fastest way to learn, create and test your Regular Expressions is using Regex 101.

I solved the Kata using Typescript and this is my final code:

This piece of code would not be suitable for production. It does not take into account of malformed filenames, it would not work for windows;
It would have problems with folders that contain a “.” etc.

If you would be using NodeJS you would use the existing functions in the Path Module.

Notes on MITx: 6.005.1x Software Construction in Java (Week 2)

This week the course is covering another two very important topics: Testing and Specifications.

LECTURE 3: Testing

Testing is a very important part of creating functionally correct programs.

Testing will be always incomplete

You will try to test your program using three methods:

  1. Formal Reasoning, essentially you manually verify that your program works correctly
  2. Code Review: Another Programmer takes a look and says everything is ok.
  3. Test Suites: Essentially you write another program (which can have its own bugs) to test your program. You define the inputs and the expected output and compare them.

The course mentions again the residual defect rates of 1-10 defects/kloc(1000 lines of code). Again this does not cite where this number actually comes from. Especially when using Industry Standards and Test Suites this high number would drastically drop to an much lower number. However in the end it only would remain to be an assumption since the actual number cannot be determined.

You testing your program for every possible input (Exhaustive testing) is not feasible. The strategy to simply take a look and see if it works (Haphazard testing) will also not reveal all bugs. The same is true for “Random” testing. All of these test methods cannot be used to test software.

Write Tests

When you are writing tests you should think about how you can make your program fail. Test drive development takes the following approach.

  1. Specify what you want to program
  2. Write tests that would test the specification
  3. Write code so that your code passes the tests

The specification is key to define what inputs are possible and which outputs will be produced. (This also includes throwing errors)

Blackbox testing only focuses on the input and output of the function. These tests do not take into account how the algorithm actually works.

The alternative is Whitebox testing takes into account how the program is implemented.

Test Coverage

Now that you have written tests for all of your code, did you also test all of your code? Coverage takes a look at if all Statements and all possible paths through your code are covered.

There are various Code coverage tools available that you can run and then visually see which part of the code is covered by your tests.

In reality you should try to achieve a coverage of 70-90% of your code achieving 100% is usually not possible due to time constraints. Of course this is not the case if you are using Test Driven Development.

Running Tests

Usually you would create a Testsuite of Unit Tests. You should integrate these tests into your build process to ensure that the tests run automatically. Especially when you modify existing code this will ensure that your modifications will not accidentally break something unintentionally.

When working with multiple people you should add hooks to your git repository that it rejects code that does not pass your test suite.


LECTURE 4: Specifications

This lecture is going to cover preconditions and post-conditions in method specifications, and how to write correct specifications.

What is a specification?

The lecture defines a specification primarily only concerning how the interfaces are defined and how the specification document essentially is used as communication device to talk to the client.

Now this actually assumes that the client is another programmer that wants the module/system to do a specific functionality. In my work experience usually the client has no technical background and expects the programmer to know what he wants.  Yes the specification is the key document on how to negotiate which features etc. the client requires, it is however not exactly defined which functions or how interfaces should be created, this is usually the task of the programmer.

The course actually is more talking about a documentation document how and which interfaces exist in the code you are programming for the client. The documentation is key whenever other programmers need to use the code you have programmed.

In either case, the specification document is a key document. It defines the work that needs to be done. The document shields the programmer from the client, if the client forgot to specify something, thus the programmer did not implement it he can prove it was the clients fault. At the same time the programmer is bound to the document that he actually implements all features. (or negotiates, talks with the client that the functionality is unfeasible, or not possible to be implemented)

Pre and Post Conditions

For each function you require the preconditions (what inputs) and postconditions (what outputs).

The inputs may have to have a specific structure, cannot be a certain value etc. These need to be checked.

The function also will have various outputs. This is of course the result, and how the result should be structured, the method also can throw errors.

Write test cases

Essentially if the specification of the function is well defined it is very easy to write the test cases. You simply follow the specification write tests to get the expected correct results and willfully pass wrong arguments into the function.

The rest of the lecture covers how to throw Exceptions. Which to use when.


Again another batch of “Java Tutor” exercises. They were as exciting as the last batch…

However this time they also provided a “warm up” problem set. The warm up is just to implement the mathematical “quadratic roots formula”.

The straightforward implementation of the formula will not pass all the Unit Tests. You need to take a deeper look at Java to actually figure out why the last Unit Test fails, and how you can change your code to make your code pass the test.

© 2017 Neal Bürger

Theme by Anders NorénUp ↑