Blog

• http://www.b.shuttle.de/hayek/mediawiki/w/index.php?title=Main_Page#technical_topics_.E2.80.93_spreading_the_word_.E2.80.A6

Last not least I can always look at my blog entries to find something exciting to talk about.

• https://www.maketecheasier.com/how-to-setup-dual-monitors-with-xrandr/
• https://en.wikipedia.org/wiki/RandR

My current employer gives me the opportunity to get familiar with quite a lot of his employees – they keep assigning a new desk to me every now and then, like once a week. I find making new friends and extending my social (scientific) network quite interesting and helpful.

And “change” is the challenge, that faces you with a plenty of tasks and experiences – and last not least extends your compentence 😎

Today I am settling at a desk with just one monitor. The desk’s monitor had been resisting to the charms of a second 19″ monitor, but I don’t really agree to that kind of reduced working conditions. I found the confirmation and the support of the sys admin (our connection: “.ro” ancestry 😆 ). But after I physically attached the 2nd screen (both through DVI), the left and the right monitor showed up as right and left. On my own SUSE Linux I would start yast straight away, but at work the sys admin was not around for a while …, so no yast right now.

But another helpful colleague pointed me to xrandr – and bingo!

Some web research lead to me this:

# lists the available monitors and their ids:
$ xrandr -q
…
# switches the logical side-by-side order:
# (maybe you will need it the other way round)
$ xrandr --auto --output DVI-I-2 --right-of DVI-I-3

Maybe somebody out there will find this text helpful. Writing it did in fact help me coping with the “pain of learning”  😯

• https://en.wikipedia.org/wiki/Bootstrap_(front-end_framework)
• http://getbootstrap.com
• http://blog.getbootstrap.com
• http://shop.oreilly.com/product/0636920027867.do
• https://www.safaribooksonline.com/library/view/bootstrap/9781449344573/
• https://github.com/whyisjake/bootstrap
• https://github.com/whyisjake/Bootstrap/blob/master/pdf/drafts/intake.pdf – the “draft” of the O’Reilly book

I am quite thrilled …

• http://getbootstrap.com/getting-started/ – the “Basic template” HTML shown isn’t XML-ish enough for my Emacs’ nxml-mode: lots of unclosed tags  🙁

How often do you hear people say things like this? “Our JavaScript is a mess, but we’re thinking about using [framework of the month].“Like it or not, JavaScript is not going away. No matter what framework or ”compiles-to-js” language or library you use, bugs and performance concerns will always be an issue if the underlying quality of your JavaScript is poor. Rewrites, including porting to the framework of the month are terribly expensive and unpredictable. The bugs won’t magically go away, and can happily reproduce themselves in a new context. To complicate things further, features will get dropped, at least temporarily.The other popular method of fixing your JS is playing “JavaScript Jenga,” where each developer slowly and carefully takes their best guess at how the out-of-control system can be altered to allow for new features, hoping that this doesn’t bring the whole stack of blocks down. This book provides clear guidance on how best to avoid these pathological approaches to writing JavaScript:

1. Recognize you have a problem with your JavaScript quality.
2. Forgive the code you have now, and the developers who made it.
3. Learn repeatable, memorable, and time-saving refactoring techniques.
4. Apply these techniques as you work, fixing things along the way.
5. Internalize these techniques, and avoid writing as much problematic code to begin with.

Bad code doesn’t have to stay that way. And making it better doesn’t have to be intimidating or unreasonably expensive.

• http://shop.oreilly.com/product/0636920053262.do

• http://EditorConfig.org

EditorConfig helps developers define and maintain consistent coding styles between different editors and IDEs.

• https://en.wikipedia.org/wiki/Quanta_Plus

• http://shop.oreilly.com/product/9780596100506.do