Category Archives: development processes

Blisk – a Browser to Make Web Programming Easier

Mobile first! Seriously? Do you really optimize your application for mobile usage?

Actually, you can’t. The current state-of-the-art makes it difficult to adopt the “mobile first!” approach seriously. Mind you: that would require you to program your application on the phone instead of using your desktop browser. Until today, I’ve seen such an approach only with iOS programming and with UWP/Xamarin. The application is developed on the desktop, but run and tested on the cell phone or the tablet.

The other day a friend of mine, Dario D´Urzo, showed me another option for web developers. What started as a small JavaScript plugin two years ago has evolved to a full-blown browser in 2016. More precisely, it’s a browser based on Chromium which adds a number of tools dedicated to web designers and web programmers.

Targeting multiple devices

When you open a URL in Blisk you’ll see the web page twice. On the right-hand side, there’s the desktop view you expect. On the left-hand side, you see the same page in a simulated smartphone. As you can see in the screenshot, both views are remarkably different. It’s great to be able to seem both views at a glance. This enables you to truly adopt the “mobile first!” slogan. Even better: if you scroll one of the windows, the other windows scrolls simultaneously. Thus you can compare both the look and the feel of both displays.

Blisk supports a number of devices out of the box. It doesn’t cover every smartphone and every tablet available on the market, but the number of devices seems to cover almost every use case.

Multiple inspect views

Seeing multiple devices at a glance is just a start. You can also open device-specific developer tools and keep them open simultaneously. That, in turn, allows you to find differences between devices a lot faster than with the traditional single window.

Limitations

Being a browser based on Chromium, I’m pretty sure Blisk has an annoying limitation: it doesn’t simulate the device completely. It only modifies the screen estate the replaces the mouse pointer by a large finger touch point. What it does not do is to simulate the rendering engine. If there’s an incompatibility because – say – Safari implements a feature differently than Chrome does, you’ll still miss it with Blisk. You still need to test your application with the real device.

Automatic reload

That’s another feature I’m told to be very useful. You can configure Blisk to watch certain files or folders. When you edit and save a file, Blisk automatically reloads the page. I suspect that’s one of the features that are useful to some and annoying to others, so probably it’s good news you can also switch it off. However, if your application supports reloading, I imagine that’s a tool boosting productivity.

Code analysis

Currently, that’s only a promise. The module providing static code analysis is still under development. I’m looking forward to it. Integrating code analysis into your browser (i.e. your runtime environment) might make you aware of problems much earlier than with traditional approaches such as SonarQube.

Screen shots

Another feature that’s still under development. However, I doubt that’s a killer feature to me. Tools like Greenshot integrate so nicely into my PC I never considered taking screenshots awkward. So I’m curious – maybe the developers have a clever idea I missed?

Integration with other tools

That’s something offering more potential to boost productivity. Blisk offers to provide integration with third-party tools, such as bug trackers and project management tools. Unfortunately, this is another module still under development.

Licence

Blisk has a long licence agreement, but basically it’s free both for commercial use and for personal use as long as you don’t modify it.

Wrapping it up

As long as you are aware on the limitations, Blisk is a great tool for every web designer and web developer targeting multiple devices. At the time of writing, many interesting features are still missing. However, what’s already there looks interesting enough to adopt Blick for development.


Dig deeper

Blick project page
Blick license agreement

Using Grunt in Mixed Java and JavaScript Maven Projects

In recent years, JavaScript is becoming more and more popular – even in Java programs. It’s hard to evade the temptation to pimp up your Java program with a bit of JavaScript here and there. Or a jQuery plugin. Before long, you’ve got a lot of JavaScript code. Now, you’ve got Maven to manage your Java builds. What about the JavaScript part of your application?

Why should I use Grunt?

Grunt is one of the most popular JavaScript build tools. It’s really powerful. Even the plain vanilla tasks are interesting enough: combine and minify both JavaScript and CSS files. But Grunt doesn’t stop there. It can also minify images, or compile LESS and SASS files to CSS. Another interesting option is to run JSHint, a tool detecting potential errors in your JavaScript code (following the Lint tradition).

By the way, I expect this article to grow over time as I gather experience with Grunt. Feel free to leave comments to foster this growth :).
Continue reading

Getting Started With Continuous Delivery

Basically, Continuous Delivery is simply a clever idea to make software development more simple, more reliable and more efficient. Sounds like simply tweaking the development process here and there, doesn’t it? But when you’re an experienced developer starting with Continuous Delivery, you’ll be surprised to meet a whole bunch of new tools you’ve never heard of. I found this pretty confusing: CD is a development process, but when I asked how to employ CD in my company, all of sudden people started to talk about tools. Worse, you’ll even learn new vocabulary, and you’ll have to acquire a lot of knowledge that’s previously been the exclusive domain of your operations department.

On second thought, that’s not surprising: One of the key ideas of Continuous Delivery is to make developers and operations collaborate more closely (an idea commonly known as “devops”). Operations departments have always been using their own tools, and will continue to do so for good reasons, so developers have to make themselves familiar with the tools of the operations department. In particular, they have to get familiar to Unix shells, which is quite a chunk to swallow if you’re a visually oriented developer like me.

Adopting Continuous Delivery has at least three challenges:

  • The development process changes.
  • The cultural shift. Both developers and operations have to learn about each others job, and they have to do tasks they could previously delegate to “the other department”.
  • Your team has to install and use several tool they wouldn’t need without CD. Expect to invest in courses and trainings.