The Holy Java

Building the right thing, building it right, fast

Ansible Troubleshooting Tips

Posted by Jakub Holý on March 4, 2014

Few tips for troubleshooting Ansible, based on my brief experiences with Ansible 1.4 (read: do not rely on this info too much).

Run ansible-playbook in the verbose mode

ansible-playbook -vvvv ... will provide you with plenty of details of what is going on. (Notice that additional v:s, starting from none, add more detail.)

Use ./hacking/test-module

Check out Ansible sources and use the ./hacking/test-module script – see Developing Modules.

Read the rest of this entry »

Posted in Tools | Tagged: , | Comments Off

Most interesting links of February ’14

Posted by Jakub Holý on February 28, 2014

Recommended Readings

Development

  • Nathan Marz: Principles of Software Engineering, Part 1 - Nathan has worked with Big Data at Twitter and other places and really knows the perils or large, distributed, real-time systems and this post contains plenty of valuable advice for making robust, reliable SW. Main message: “there’s a lot of uncertainty in software engineering“; every SW operates correctly only for a certain range of inputs (including volume, HW it runs on, …) and you never control all of them so there always is an opportunity for failure; you can’t predict what inputs you will encounter in the wild. “[..] while software is deterministic, you can’t treat it as deterministic in any sort of practical sense if you want to build robust software.” “Making software robust is an iterative process: you build and test it as best you can, but inevitably in production you’ll discover new areas of the input space that lead to failure. Like rockets, it’s crucial to have excellent monitoring in place so that these issues can be diagnosed.“. From the content: Sources of uncertainty (bugs, humans, requirements, inputs, ..), Engineering for uncertainty (minimize dependencies, lessen % of cascading failure [JH: -> Hystrix], measure and monitor)
    • Suffering-oriented programming is certainly also worth reading (summary: do not start with great designs; only start generalizing and creating libs when you have suffered enough from doing things more manually and thus learned the domain; make it possible > make it beautiful > make it fast, repeat)
  • ThoughtWorks open-sources Go, continuous delivery platform - good bye, Jenkins! – better support for pipelines etc., see features and elementary concepts
  • Cloud Design Patterns: Prescriptive Architecture Guidance for Cloud Applications (recommended by @markusbk so it must be good); Patterns: Cache-aside, Circuit Breaker, Compensating Transaction, Competing Consumers, Compute Resource Consolidation, Command and Query Responsibility Segregation (CQRS), Event Sourcing, External Configuration Store, Federated Identity, Gatekeeper, Health Endpoint Monitoring, Index Table, Leader Election, Materialized View, Pipes and Filters, Priority Queue, Queue-based Load Leveling, Retry, Runtime Reconfiguration, Scheduler Agent Supervisor, (data) Sharding, Static Content Hosting (-> CDN), Throttling, Valet Key.
    Guidance topics: Asynchronous Messaging Primer, Autoscaling, Caching, Compute Partitioning, Data Consistency Primer, Data Partitioning, Data Replication and Synchronization, Instrumentation and Telemetry, Multiple Datacenter Deployment, Service Metering
  • MOOC course Functional programming with Clojure at Uni of Helsinki – to get started you need, I suppose, follow the “Material and course content” – essentially read the text for each chapter, clone its repo, submit pull requests to get your work graded
  • Jez Humble: The Case for Continuous Delivery - read to persuade manager about CD: “Still, many managers and executives remain unconvinced as to the benefits [of CD], and would like to know more about the economic drivers behind CD.” CD reduces waste: “[..]online controlled experiments (A/B tests) at Amazon. This approach created hundreds of millions of dollars of value[..],” reduces risks: “[..] Etsy, has a great presentation which describes how deploying more frequently improves the stability of web services.” CD makes development cheaper by reducing the cost of non-value-adding activities such as integration and testing. F.ex. HP got dev. costs down by 40%, dev cost/program by 78%

Web

  • Client-side messaging in JavaScript – Part 3 (anti-patterns) (via @ruudud so it must be worth reading)
  • Request Quest (via @jraregris) – entertaining and educational intractive quiz regarding what does (not) trigger a request in browsers and differences between them (and deviances from the standard) – img, script, css, etc.
  • The REST Statelessness Constraint - a nice post about statelessness in REST if you, like me, don’t know REST so much in depth; highlights: Statelesness (and thus the requirement for clients to send their state with every request) is a trade-off crucial for web-scale and partially balanced by caching – while typical enterprise apps have different needs (more state, less scale) so REST isn’t a perfect match. Distinguish application (client-side) and server (resources) state. Using a DB to hold the state still violates the requirement. Use links to transfer some state (e.g. contain a link to fetch the next page of records in the response).
  • Functional Programming in Javascript – an interactive tutorial teaching map, filter, mergeAll, reduce, zip

Other

  • CodeMesh 2013 presentations - good stuff! F.ex. Refactoring Functional Programs: Past and Future, Distribution, Scale and Flexibility with ZeroMQ, Deepak Giridharagopal on Puppet, Immutable Deployments, Analyzing Systems with PuppetDB, Francesco Cesarini and Viktor Klang on the Reactive Manifesto and more
  • Cognitive Biases in Times of Uncertainty - people under pressure/stress start to focus on risks over gains and (very) short-term rather than long-term and thus also adopt 0-some mindset (i.e. if sb. else wins, I loose) => polarization into we x them and focus on getting as big piece of the cake possible at any price, now, dismissal of collaboration. With accelerating rate of change in the society due to technology, this is exactly what is happening. How to counter it? Create more positive narratives than the threat-based ones (views of the world), support them via short-term gains. Bottom line: each of us must work on spreading a more positive attitude to save us from bleak future.
  • Book – Nathan Marz: Big Data - I dislike the big data hype (and, with passion, Hadoop) but would love to read this book; it presents a fresh look at big data processing, heavily inspired by functional programming. Nathan has plenty of experiences from Twitter and creating Storm and Cascalog (both in Clojure, btw.). Read ch 1:  A new paradigm for big data.
  • Facebook Engineering: The Mature Optimization Handbook (or go directly to the pdf,   ePubMobi). If you get bored, jump directly to ch 5. Instrumentation.

Clojure Corner

  • Schmetterling - Debug running clojure processes from the browser! – upon an exception, the process will pause and S. will show the stack, which you can navigate and see locals and run code in the context of any stack frame; you can also trigger it from your code
  • Gorilla REPL (screenshot, 11min video)- interactive web-based notebook where you can mix text (with Markdown formatting), mathematical formulas via LaTeX, graphs, tables, Clojure code. Great for exploring and, at the same time, describing data. <3
  • Local state is harmful – how can we answer the questions about when/why did state X change, how did output Y get where it is? Make state explicit, f.ex. one global map holding all of it, and perhaps not just the current state but also history – thus we can easily query it. Prismatic’ Graph can be used to make the state map, watches to keep history. Inspired by databases (Datomic is an excellent example of SW where answering such questions is trivial)
  • S. Corfield: Insanely Useful Leiningen Plugins - lein-ancient (find updated deps), lein-exec (execute Clj from cmd.line / scripts in Clj), lein-try (try a lib in REPL), Eastwood - a lint tool for Clojure
  • Sente – Clojure(Script) + core.async + WebSockets/Ajax - a tiny 600 LoC library for websockets (with fall-back to long-polling) communication between ClojureScript frontend and clojure backend, using EDN, support for request-reply and multiple user windows/tabs (comparison with Chord (no non-WS fallback or req/resp))
  • Nicholas Kariniemi: Why is Clojure bootstrapping so slow? – don’t blame the JVM, most time spent in clojure.core according to this analyzes on JVM and Android (create and set vars, load other namespaces); some proposals for improving it – lazy loading, excluding functionality not used, …
  • Cheat your way to running CLJS on Node – (ab)use D. Nolen’s mies template intended for client-side cljs development to create a Node project; the trick: compile everything into 1 file so that Node does not fail to find dependencies, disable source maps etc. Update: the nodecljs template now does this
  • lt-clojure-tutorial - A Clojure tutorial optimized for Light Table, ported from Nolen’s cljs tutorial

Tools/Libs

Posted in General, Languages, Tools, Top links of month | Tagged: , , , , , , , , | Comments Off

Protected: JavaServer Faces Are Evil (draft)

Posted by Jakub Holý on February 24, 2014

This content is password protected. To view it please enter your password below:

Posted in Uncategorized | Comments Off

Handling Deployments When Provisioning JBoss domain.xml (With Ansible)

Posted by Jakub Holý on February 24, 2014

It is tricky to manage JBoss with a provisioner such as Puppet or Ansible because its domain.xml contains not only rather static configuration but also sections that change quite often such as deployments. So how can we manage the static parts of domain.xml with f.ex. Ansible while still enabling developers to deploy at will via jboss-cli (and thus changing the <deployments> sections of the file)? Here is one possible solution, based on extracting the sections from the current file and merging them into the template.

Read the rest of this entry »

Posted in General | Tagged: , , | Comments Off

Seek Understanding

Posted by Jakub Holý on February 23, 2014

The most important lesson I have learned in 2013 is that I won’t change anything by writing critical blog posts and talking to like-minded people. Fostering the “we vs. them,” we who are right vs. them idiots sentiment is ineffective, even destructive. To be able to achieve anything, I have to talk to the people with opposite opinions and understand them. They are rarely ***holes and typically have good reasons for their opinions. Only by understanding those reasons and the background, history, and emotions they stem from – and hopefully helping the “opponents” understand some of my reasons and context – we can find a common ground and common goals that we can build upon to go further – perhaps not in harmony but still together rather than against each other.

Talking to people is difficult. Having my dearly hold beliefs exposed to discussion and criticism is painful. Trying to find a common ground with people with totally different needs, experiences, and ideas about the best way to do software development in a particular context is challenging. But only by doing so, and by being open to changing my own stance, I can hope to influence the stance of other “stakeholders” and thus bring a positive change to a project or organization.

Side note: It’s funny that the more I learn about IT the more I realize that the main challenges and solutions we encounter are not about technology, but about the fundamentally human in us. Also the approach advocated here – seeking understanding and respect in spite of disagreement instead of the radically adversarial “we vs. them” thinking – is crucial not just for IT, but also for building a better society. So far it unfortunately seems that politicians – especially in the US but not just there – tend to prefer the wrong approach. And also the willingness to expose one’s beliefs to discussion and the openness to change are important not only for talking to people, but for being able to keep developing mentally and spiritually, as put so well by M. Scott Peck in The Road Less Traveled.

I’d like to thank to Markus Krüger for showing me the power of talking to people and to Marshall B. Rosenberg’s Nonviolent Communication: A Language of Life for being so inspirational on this path.

Posted in General | Tagged: , | Comments Off

The Risks Of Big-Bang Deployments And Techniques For Step-wise Deployment

Posted by Jakub Holý on February 17, 2014

If you ever need to persuade management why it might be better to deploy a larger change in multiple stages and push it to customers gradually, read on.

A deployment of many changes is risky. We want therefore to deploy them in a way which minimizes the risk of harm to our customers and our companies. The deployment can be done either in an all-at-once (also known as big-bang) way or a gradual way. We will argue here for the more gradual (“stepwise”) approach.

Big-bang or stepwise deployment?

A big-bang deployment seems to be the natural thing to do: the full solution is developed and tested and then replaces the current system at once. However, it has two crucial flaws.

Read the rest of this entry »

Posted in SW development | Tagged: , | Comments Off

Demonstration of Ansible Features With Control & Test VMs

Posted by Jakub Holý on February 16, 2014

I have created a small project to demonstrate some features of Ansible, the new DevOps hotness, including Vagrant VMs for running Ansible and for testing the configuration. Either go straight to

https://github.com/jakubholynet/ansible-example-with-vm

or continue reading the copy & paste here.

This project has three things of interest:

  1. A non-trivial Ansible configuration that demonstrates couple of useful features and tricks
  2. A Vagrant/VirtualBox virtual machine with Ansible & co. to make it easy to run it (even on Windows)
  3. Another VM that can be used to test the configuration

And of course all the plumbing that makes them work together. It might be therefore a good base for Ansible projects of your own.

Read the rest of this entry »

Posted in Tools | Tagged: , | Comments Off

JBoss Modules Suck, It’s Impossible To Use Custom Resteasy/JAX-RS Under JBoss 7

Posted by Jakub Holý on February 4, 2014

Since JBoss EAP 6.1 / AS 7.2.0 is modular and you can exclude what modules are visible to your webapp, you would expect it to be easy to ignore the built-in implementation of JAX-RS (Rest Easy 2.3.6) and use a custom one (3.0.6). However, sadly, this is not the case. You are stuck with what the official guide suggests, i.e. upgrading Rest Easy globally – provided that no other webapp running on the server becomes broken by the upgrade.

Read the rest of this entry »

Posted in j2ee | Tagged: , , | 5 Comments »

A Secret Weapon Against Technical Debt

Posted by Jakub Holý on February 2, 2014

(Cross-posted from blog.iterate.no.)

Technical debt is not the only monster we have to fight – it has a hidden evil twin,  as pointed out by Niklas Björnerstedt: Competence Debt. The rope of ignorance that binds our hands and suffocates us by fear so that we don’t dare to change the system. Technical debt makes change difficult because the structure of the system does not support it. Competence debt makes change difficult because we do not know the system well enough, what & where to change and what impacts a change may have.

There is an often neglected tool at our fingertips that might help us fight competence debt. Its name is – behold – JavaDoc. An example from practice: I have returned to a client after two years and needed to understand the functionality of a part of the system. And, to my surprise, I found my own JavaDoc providing exactly the answer I was looking for. A colleague of mine mentioned that I should get the award for the “most documenting developer”. But I don’t do it for fun or just to help my bad memory and to be nice to my colleagues. It is an important contribution to the fight against the ever growing hydra of legacy code. Next time you code, try to remember that you are not typing code, but fighting. As every fight, it is hard – but do not give up or the enemy will prevail.

Side note: Writing JavaDoc that helps yet is not too verbose and not too likely to get outdated soon is hard. Getting the right balance – neither too little nor too much, focusing on the why and the broader context and relationships instead of the changing implementation etc. is difficult. But it is worth it. Help yourself, help your fellow colleagues, strike the hydra. Write good JavaDoc.

PS: This post is about competence debt even though the title mentions technical debt, sorry for the confusion (even though they are two sides of the same coin). And “good enough” documentation, though important, is not the sole remedy, as well as developers’ lack of knowledge is not the sole cause of competence debt. Also, Niklas provides a more in-depth review of the technical & competence debt terms in Misunderstanding technical debt  (tech. debt as evolving understanding [but not code] and crappy code). He wrote also A deeper look at Competence debt.

Posted in General | Tagged: , | Comments Off

Most interesting links of January ’14

Posted by Jakub Holý on January 31, 2014

Recommended Readings

Clojure Corner

Tools/Libs

Favourite Quotes

Boeing about unavoidable child issues with the new Dreamliner aircraft:

Nei. Selvfølgelig vil man at alt skal være perfekt. Vi gjorde mer testing på dette flyet enn vi har gjort på noen andre fly. Du kan teste og teste, men realiteten er at du ikke alltid vil finne alt. Ingen fly har blitt satt i drift og oppnådd 100 prosent pålitelighet med det samme. Noen oppnår det aldri, svarte Fleming.
- DN.no – Vi har gode og dårlige dager 2014-01-24

Posted in General, Top links of month | Comments Off