pwmarcz.pl

Conference: AgileByExample 2015


AgileByExample was a Warsaw conference on agile software development. I attended two days of workshops and learned a few new things about communicating with people, organizing work and developing a product – overall, time well spent.

The talks were organized by three tracks: team, product and business. Here are some things I noted down.

Book: Time Management for System Administrators by Thomas A. Limoncelli


This short book may have been written for system administrators, but as a software engineer I found it no less helpful. In fact, there is not much content specific to technology, either. What you will find inside is a bunch of "street-fighting" techniques for managing your time that you can use whenever you find yourself juggling many tasks and requests from other people; regardless of what your actual job is.

The author describes a simple system of preparing a to-do list for a given day, then moving any "spilled over" tasks to the next day, as opposed to having a huge ever-growing master list that you will never clear. There is interesting advice regarding prioritization: apart from estimated effort and urgency, you have to also consider what delivery time your customer is expecting. If they know you can do it in 5 minutes, better do it soon. If you can do it in 5 minutes but they only expect it the next day, you can start with something more important.

Another good piece of advice is to avoid conscious thinking about things that you can do often, but "solve them once and for all" by making them routine. For instance, the author always holds the car keys in one hand while closing his car: he has incorporated an "automated check" that helps him avoid locking the keys in. Another example would be always doing some things (like buying new supplies, or doing your laundry) at a given day of week, instead of constantly worrying about when exactly you need to do it.

For a more sysadmin-specific example: whenever you're adding a firewall rule, first verify that whatever you want to block is NOT blocked, then add a rule, then check whether it's blocked now, so that you're sure your rule blocked the right thing. The practice should sound very familiar to programmers writing automated tests: first, write a test and make sure that it fails. The same applies to reproducing a bug before you go on to fix it.

The book also covers dealing with being interrupted by other people's requests: if you cannot do them immediately, make sure to record them or delegate to others; and make sure the requester knows what you're doing and is reassured that the request will not be forgotten. Apart from that, there is advice on how (and when) to automate tasks, how to write useful documentation so that you can delegate things instead of doing everything yourself, and even how to handle longer projects and even life goals (although without many specifics: the book is more focused on day-to-day planning).

Overall, the book offers a lot of small pieces of advice, as well as a good mindset: keep a single system of notes that you can trust instead of holding everything in memory, and make simple routines instead of wasting your attention on trying to handle everything optimally. Definitely worth a read!

Conference: PolyConf 2015


This year's PolyConf, a "polyglot conference", had a slightly lower insight-per-hour rate for me than the last one, but still turned out to be pretty good - especially since it was one day longer this year. Here are some of the interesting things that I heard about:

Book: The Effective Engineer by Edmond Lau


The main idea of this book is simple: as a software engineer, you have plenty of opportunities to optimize what you're doing for higher impact. The book provides plenty of advice on how to identify which activities make the most difference in whatever you're trying to achieve (have the most "leverage", as the author says).

A good example would be taking some time to automate things you would do manually. This in a sense generalizes to having tight feedback loop, for instance a fast compile-run cycle, or a way to reproduce a bug you're working on quickly. The book also talks about importance of having good metrics (as opposed to "flying blind") and systems that fail fast (so that you immediately know what is the source of failure).

Of course, writing software is not the only area where you can go looking for "high-leverage" activities. There are things like recruitment, onboarding and mentoring new work-mates, which pays off in terms of these people being able to contribute to your project. And on the individual level, it's important to optimize your own learning, since that will generally become more useful later than money from a well-paid, but interesting job.

Overall, the book is full of unsurprising but generally useful software engineering advice on various aspects of the programmer job, like working with code, estimation, team work or risk management. The examples get boring at times - hearing for the Nth time what this or that famous company did gets old quickly, and gives an impression of a typical American self-help book. I liked some stories, though. I learned for instance that Dropbox uses fake traffic to detect problems with site load quickly - if they notice a problem, they simply turn it off and investigate the issue without any time pressure (which they couldn't do with real traffic)!

The most important part that I got from this book, however, wasn't any specific engineering tips (which you can easily find elsewhere) but the attitude of "leverage": don't waste time on unimportant stuff, go look for things you can do that will matter the most.

Book: The Art of Game Design by Jesse Schell


This is a shockingly comprehensive, and at the same time very easy to read, introduction to game design. The book touches on aspects ranging from game mechanics, aesthetics and technology considerations, to teamwork advice and design documents.

Overall, the book gave me a lot of respect for the complexity and size of the field. As a game designer, you have to draw from a big number of disciplines such as anthropology, psychology, sociology, architecture, probability theory or graphic design. You have to think about what needs of the player your game satisfies (think Maslow's hierarchy, but not only), how to maintain the difficulty curve so that the player is in the "channel of flow" (not too easy, not too hard), how to balance your game with respect to different axes, what theme the game will have and how to use every aspect of design to reinforce that theme, and so on and so forth. There is also some advice on brainstorming and working with a team which can be easily applied outside of the field of game development.

All these ideas are neatly categorized in the book's chapters, and in each part I found some interesting insight. To give one example, there's a concept of game venue as something that defines the type of play experience. The author mentions venues like the hearth where people gather together (modern hearth being, well, the TV with a console), your personal workbench where you concentrate on things (desktop PCs would fill this niche, with PC games being more "serious" and less casual), the reading nook where you sit comfortably with a book (or a tablet), a table for board games, public spaces like arena for competitive games, and so on.

Another example is the well-known notion of "emergent gameplay" that somehow always felt like a magic to me – my understanding of it was "create a sufficiently complex game and it will magically become more interesting because of what the players come up with". The book breaks it down nicely: a game can have basic actions which are basically rules of the game (for instance, move a piece or capture a piece) and strategic actions which are implied by these (for instance, move a piece to protect another one, sacrifice or exchange pieces, force an opponent to do something…) It's generally good to have a small number of basic actions from which many strategic actions can emerge. A good way to achieve that is to make each of this actions meaningful, e.g. have far-reaching consequences instead of just local ones.

That's just a small sample of things I took away from The Art of Game Design. I borrowed the book from a friend but I think I will be buying my own copy, since I definitely plan to return to it in the future.

Conference: PyWaw Summit 2015


I just came back from PyWaw Summit, a two-day Python conference here in Warsaw. Here are some interesting take-aways I had:

That's all for now - until next time!

Conference: ScotlandJS 2015


I just finished ScotlandJS, a two-day conference full of talks about JavaScript and frontend technologies. I'm very satisfied with the overall level of talks and number of ideas I got there. Here are some things I found worth noting down. As always, written in hopes that I'll encourage others to attend more events like that.

Finally, there was a closing keynote about diversity in tech that I found valuable. The fact that the tech scene is demographically monolithic, and at times very unfriendly to women and other underrepresented groups is quite well documented, but the speaker also touched on a few other issues.

The talk (and a positive response from the audience) gave me much respect for the British frontend scene, especially compared to the Polish one (post in Polish, and a somewhat unpleasant reading).

That's all I have - I hope you enjoyed my writeup!

Book: The Clean Coder by Robert C. Martin


Yes, the "r" is no mistake - this is a book on what it means to be a professional programmer, someone who has a programming job and takes it seriously.

The book teaches you to take pride in what you're doing, to stick to good practices (especially under pressure) because that's the ethical thing to do, to not cave in and "just try to do it faster", but at the same time to take responsibility for what you're committing to. It reminds you that requirements are not set in stone, that the client might not know really well what they want and it's your duty to help them figure that out.

It also gives good advice on several subjects both technical and soft, like estimation, TDD and different kinds of testing, mode of work, and time management. The author shares many war stories from his 40-year-long software engineering experience, talking about how to avoid his mistakes.

Some of it is very opinionated (it's Uncle Bob, what'd you expect) and I didn't agree with everything, but some things rang very true for me and actually were painful to read. I had to look at the areas where I'm not behaving like a responsible professional; overlooking broken windows, not managing my time properly, concentrating on broken requirements instead of the overall goal.

On the other hand, it was nice to see some confirmation about things that I'm just discovering for myself now, like the effectiveness of pair programming or that one person shouldn't juggle several projects.

I highly recommend the book to all professional programmers.

Some of my takeaways:

Conference: PolyConf 2014


I just finished PolyConf, a two-day "polyglot programing conference", and I'm really excited. There were a lot of really interesting talks so I want to share it all with you. Here are some of the things I saw:

And that's not even mentioning everything (there was also F#, some Rails Girls and PyLadies, a few more philosophical talks…) So all in all, a great conference that I'll definitely attend again next year.

I hope you enjoyed this write-up and feel encouraged to attend more events like that!

Book: Clean Code by Robert C. Martin


The examples are "very Java" at times, and you might not agree with all the choices the author makes, but don't be discouraged: the book gives you some very useful principles about how to structure your code, split it into simple parts, and generally avoid making a mess (I think the most valuable one was operate on a single level of abstraction at a time). The book includes real-life examples that are really helpful for understanding.

Overall, I think my time reading this book was well spent.

Some important points:

Writing a roguelike in Lua


(adapted from a post on Reddit)

I recently wrote a seven-day roguelike in Lua. It was my first project in Lua, and second roguelike (after coding one in Python a year before). I don't have much to base this on, but believe dynamic languages like this are the fastest and best way to write a roguelike game. You write relatively little boilerplate and have much freedom with how to design the engine, compared to, say, endless classes bureaucracy in Java or manual memory management in C.

Coming from Python, several things irritated me. The language feels lower-level. There are less primitives available from the start. Everything takes more code to write. While the tables are a nice concept, often I missed working with real lists, tuples and arrays. Also list comprehensions, everything being a sequence. Ternary if. Multiple return values, and unpacking, instead of simple tuples. Optional arguments… the list goes on.

Most of the things I wanted I could actually do in Lua, but it seemed more verbose and more prone to failure. Of course, in part this is probably due to my inexperience. And I was probably trying to mimic the previous (Python) engine's architecture too closely.

I loved being "close to the metal" - actually understanding how the tables/methods I use actually work. Classes in Python feel too heavy sometimes (and definitely more magical, harder to understood, and uglier). In Lua, the whole thing seems very malleable. This is a language you can make every object system you can think of, after all.

As for having to define all the OOP-style mechanisms from scratch - this is, IMO, a non-issue. After writing an object system, using it was as easy as everywhere else. I even managed to hack some field-imitating class properties.

It frightens me how easy it is to make an error in Lua. All it takes is to forget a local before a variable, or mix up foo:bar() with foo.bar() - and the error may not surface at all until much later (unless you bother to make tests… I probably should have): the system doesn't complain if you do .bar() instead of :bar(). It doesn't complain if you give it wrong number of arguments. Reading an uninitialized variable gives you a silent nil. Bugs not failing early enough are a problem in most dynamically-typed languages, but somehow in Lua it seemed especially bad.

(Some of these are fixable, for example you can easily forbid making global variables, ensuring that leaving out a local will blow up).

There is no built-in module/namespace system, just loading files. Well, actually there is the module() function, but from what I've read, it's considered deprecated and harmful…

Numbering arrays starting from one is an ugly wart. Of course, everyone tells you that you get used to it, and they're probably right… but I haven't seen any argument about it being superior, just about not being important. Still looks ugly. Especially when if you interface with a library that counts from zero. But this is nitpicking, the language seems very well designed apart from that.

Keep in mind that I'm a beginner and I don't know what I'm talking about. If I stayed with Lua for some more projects, I probably would've stopped whining about it not being Python and learned to appreciate it more. Also, the experience wasn't as bad as my negative comments here would make it seem.

tl;dr Try it.

ADOM playthrough: Vicious, a human assassin


(originally posted on Reddit)

This is a story of Vicious, a human assassin who managed to save the world.

Screenshot

As he enters the Drakalor Chain, he has no name yet… He will have to earn it.

Screenshot

Starting equipment. Not bad, I think. We'll start with daggers - both in melee and thrown.

Screenshot

Ogre mage - has invisibility and frost bolt. I was certain the death is close. Fortunately he turned out to be friendly…

Screenshot

Somehow I managed to reach Dwarftown. As you can see, dwarf grandpa's first quest is a rather easy one.

Screenshot

This is me having some trouble with the animated trees. I seriously thought I'm out of luck when they suddenly refused to let me pass. Fortunately when I calmed down, the solution turned out to be simple - potion of invisibility.

Screenshot

Rehetep, the mummy lord, was quickly dealt with. Assassins are very good at shooting.

Screenshot

The character has been quite successful, I think he deserves a name. Meet… Vicious.

Screenshot

Trying my luck with steel golems in Darkforge. As you can see, a bad idea. I could damage them only with arrows of construct slaying and they quickly run out.

One of the golems refused to let me go. Fortunately…

Screenshot

Most of the time "True Aim" and "Thunderstroke" are useless shit. Come on… artifact ARROW? But somehow this time, being the weapon with best damage I had, it proved quite useful - shoot the golem, run around, pick up the arrow, shoot it again…

Screenshot

Digging some graves on the dwarven graveyard. No good loot, only a troublesome master lich sleeping in one of them.

Screenshot

My visit to Gremlin Cave was more fruitful - I managed to find seven league boots. A very useful item - doubles your movement speed.

And now…

You slip...
You fall...
*BLAMMMM!!!*
You have reached the bottom.

Screenshot

This is how you usually enter the Rift - Climbing at 100, and still the landing is quite hard.

Having in mind the sad story of Tesuji the drake assassin (destroyed his only climbing set in this jump, then spent rest of his miserable life trapped beyond the mountains trying to find a new one - and finally petrified by a gorgon) this time I took two climbing sets. Both survived the fall.

Screenshot

And that's why you enter the rift. Awesome library filled with useful scrolls and books. And, sometimes, artifacts - here I found the sapphire amulet "Preserver".

Screenshot

Drinking from pools can get you a free wish. Or a dooming curse. They say the probability is the same. Somehow, I don't believe it.

Screenshot

This was scary. Never fall asleep at the wheel. I started playing "on autopilot" and suddenly found myself face to face with a gorgon. One more turn and I would turn into a statue.

Screenshot

The Casino. Lots of gambling machines and a huge shop. There is a way to get practically unlimited money playing on the machines - just find the best one, put something on your Enter key and wait some time… I consider it terrible, anticlimatic farming bordering on cheating.

Screenshot

Cat Lord was generated when I had 18 cat souls on my conscience. I was afraid direct confrontation would be my end - so I Acidballed him through a wall :)

Acid Ball rocks. Did you know you can kill even the Elder Chaos God with it?

Screenshot

A room full of Ghost Kings… If I started to fight them, the poor human would die of old age in no time… Fortunately I managed to escape without being noticed.

Screenshot

You feel truly excited.

And for a good reason - these greater vaults often contain artifacts and much good loot. Not to mention lots of exp.

Here we see a vault of fire creatures - dragons, fire elementals and such.

Screenshot

This is me remembering that fire burns. That was my best bow…

Screenshot

One more extremely annoying location - the blue dragon caves. Full of lightning-breathing dragons ready to destroy every burnable item you have.

But for killing this fellow I get a certain rune-covered dagger called "Needle". And once I obtain another one called "Sting"… Neither of them is very powerful on its own. But when I wield both of them:

Right hand: +230 bonus to hit, 3d4+116 damage
Left hand: +228 bonus to hit, 3d4+116 damage

Sting & Needle - the deadliest combo in the game.

Screenshot

Emperor moloch in his castle. In all his armor he's like a walking tank. I guess assassin's arrows are better than anti-tank missiles.

Time to save the world!

Screenshot

First time a balor has ever surrendered to me. I had to kill him anyway - he kept opening the Chaos Gate and I couldn't leave the level with him around.

Screenshot

This time I wiped out the whole level. For a moloch-armor-covered (81 PV!), Sting-and-Needle-wielding walking tank it was very easy.

THE END


Character dump

Photos, full recording (in DOS Recorder) and final savegame

I think this was the strongest PC I ever played. High-level assassin is easier than a barbarian. And because of Backstabbing and other class skills he doesn't even need an artifact/slayer weapon - he manages to score critical hits with everyting. Most of the game, Vicious used a plain sword of sharpness.

Hope you liked it!