JIRA

There are many good systems for doing the bug report tickets. Good open source tools. Some people like HP-Quality-Center. But most developer teams seem to like Jira, because it is easy to use, has hosting options and good functionality and stability. Also there are ways to support modern agile development styles like Kanban and Scrum. And it comes with a nice Wiki that apparently has partly or fully replaced Word documents in most projects that I have seen over the last 10 years.

Please remember, it is pronounced [ˈdʒi.rɑː] and not [ˈdʒɑi.rɑː]. For English speakers: think of „Jeera“. For German speakers: think of „Djihra“. The word is of Japanese origin and usually it does not work to apply an assumed English pronunciation to any non-English language. English is to irregular to guess the pronunciation without knowing the word for most of us. And more irregular than most other languages.

Share Button

Shell Scripts

Shell scripts can be useful for writing small stuff like combining a few commands to pipes or doing a bit of „back ticking“. Even simple loops and if-conditions are possible. And if we want, it is almost a full programming language. A bit hard to tame, maybe, but quite a lot of stuff is possible. Those who like to know more about it may look into startup scripts of typical java software. Often a .bat and a .sh file are provided, where the right jvm is found, the classpath and the execution path and maybe some other environment are put together. In the end the .sh-file is quite a long and unreadable horror story and the .bat file is even much worse, because the cmd-language is just a lot more primitive and less capable and requires even worse hacks.

There are ways to make shell scripts more readable, which by themselves are truly admirable, but I think that route is wrong. We can learn all the Shell functionalities and understand bit by bit even more complex shell scripts, but I think for non trivial shell scripts it is time to switch to real programming languages instead. Scripting languages, of course, for example Perl, Ruby, Python or Lua. We may still execute „shell commands“, that are actually programs in /bin, /usr/bin or /usr/local/bin where they are powerful and more concise than writing purely in that programming language. But a magic for putting together a classpath is much cleaner in Perl than in pure bash (or worse cmd/bat).

This is of course another example of the Golden Hammer anti pattern. We should balance our tool box. Not add specific tools for making any minor task a bit easier on the expense of supporting one more tool, but keep a broad range of tools that in conjunction are very powerful. For example I would retire awk and sed and use either Perl or Ruby instead. We only have to keep them around because a lot of system tools that are just there still rely on them, but for a team I would deprecate awk and sed for new scripts or even for enhancing existing scripts. Bash would be ok only for small scripts, you can invent a line number or a maximum complexity, but for very short scripts I think bash is a legitimate tool.

Switch to Perl, Perl6, Ruby or… when you encounter any of the following:

  • The scripts is getting kind of long (>= 100 lines)
  • You find yourself modularizing it with functions
  • You find yourself using non trivial perl, ruby, sed or awk within the script, for example regex-stuff
  • The script need interaction
  • The scripts needs arrays, numbers or other types
  • More than one or two trivial if-statements or loop-statements are needed
  • Database access is done by the script (SQL or NoSQL)
  • String encoding becomes relevant
  • Quoting levels become an issue

This post was inspired by a similar post on the Isoblog by Kris. And the Shell Style Guide of Google is quite good especially in limiting the area where shell scripts are acceptable.

Share Button

WLANs

We use our computers and other devices everywhere. While phones are of course equipped with a SIM card that at least part of the time allows relatively cheap internet access via the GSM-network (of course today UTMS or LTE or whatever comes next), laptops usually do not have SIM cards, even though they could. So we rely on these WLANs that we find in Cafes, gas stations, shops, hotels, camp ground, airports, train stations, trains and sometimes even in cities. While we are used to paying for our SIM cards monthly fees or even volume based fees, the question if it should cost money to use a WLAN is still open. Some years ago the WLAN cost extra in most places. The problem was, that the effort for collecting the money was by some orders of magnitude higher than the effort for actually providing the WLAN, resulting in prices that were way too high. So the normal model is now that we pay for the camping, train, flight, hotel, coffee or whatever and some very very tiny fraction of this money is used to implement the WLAN. It does not hurt the people, who do not use it, because it is so little.

Now there are some ways to get into WLANs, which we all know too well:

  1. Open WLAN: just use it
  2. Password for WLAN required
  3. „Open“ WLAN, need to confirm the conditions
  4. „Open“ WLAN, need to provide phone number or email address with some verification
  5. „Open“ WLAN, need to give username + password on some page

While (1) is of course ok from a user point of view and (2) works very well for small sites like hotels, the other approaches are somewhat problematic and fragile.

They all rely on the assumption that the device uses the DNS as is provided by DHCP from the WLAN or on an intercepting proxy. Anyway, the network is in two different states. In the first state it does not behave regularly, but going to any page with the browser will actually lead to the login page. The internet will not work in the beginning, even though at network level everything is there, just the routing or maybe the DNS or the Web-Caching are skrewed up. My phone detects such a skrewed up internet and by itself opens the „login“-page by going to www.google.com, which of course is today https://www.google.com/. It won’t work, because it leads to a fake „www.google.com“, so the https-certificate is not correct and the browser refuses to show it, unless we really ask for an exception, which I would not recommend. Knowing this, we can always overcome the problem by just surfing to any site that is still not https and that is not in the browser cache. This is going to become harder, but is still possible. Is it ugly? I would think so. Even worse, there is a time window for doing this, and sometimes the login does not really work well, so we need to try it over and over again, until it finally works or we give up and use the phone as a temporary WLAN-router, hoping it will not break out of our free Megabytes. Verifying a phone number is not too bad, because via SMS there is a channel independent from the WLAN to transmit the verification code. Do we have a phone? I guess so, people without phone are really very rare, so I would consider that ok. Why do they need this information? Should they ask for it? I do not think so… It depends of course how much we trust in our current and future democracy and in our government and company organizations constraining themselves to legal and ethical conduct. But from a purly technical point of view this kind of works. The email is kind of cute. To confirm it, we need access to our email system, which in turn already requires internet. But it happens. Just confirming „terms and conditions“ is also kind of cute, because the option of actually reading them is offered, but rarely used. And they would know it, if they just looked into their logs.

So I would really love to just use the internet and I would really love to rely on people using the internet to behave legally and ethically without going through long terms and conditions. Maybe those who provide the internet need these, to ensure that they do not have to pay for fallacies of their internet users, but making them pay is not really a good idea. A criminal offense is the fault of a criminal and not of those who provide some common infrastructure for communication that is in no way specific to criminal activity. Actually those who are somewhat skilled in criminal activities also know their ways to hide their identity when using some WLAN.

The last one is kind of tricky. It does have some justification, because it allows for more fine granular access. But it still uses somewhat broken mechanisms by providing a broken internet to log in and then the working internet. I think it would be better to extend the WLAN standard to provide for a username+password-login instead of only using a password for the WLAN.

Btw., I recommend to assume that the WLAN is not safe and always run a firewall against the WLAN and do delicate access to other systems via the WLAN using a vpn like OpenVPN or of course encrypted variants of common internet protocols like ssh, https etc. The older WLAN encryption standard was just a joke. The current one is kind of ok but I prefer not to trust it. Since we use our devices in all kinds of WLANs anyway, trusting some WLANs and not trusting others is just too much risk in terms of misconfiguration. And as soon as we are accessible via the internet, the attackers are already there and scanning ports and some common URLs. If they are in the WLAN or not, I do not want to rely on them not being there…

Share Button