A dev’s MacBook from scratch

Share on Facebook8Share on LinkedIn0Tweet about this on Twitter

I’ve been a long time Apple user. I hate a lot about the company’s policy and how they treat their power users, but I love the tight integration between their software and hardware. Another thing to love is their migration tools. You buy new hardware, you click Restore from backup and you are done. Safari even opens up the tabs you had open on the old device. However recently, I’ve splurged on a new MacBook 12” and decided to set it up from scratch. For the fun of it. Here are some notes of how I’ve set it up for myself, for future reference and if someone is in a similar position.


  • Don’t sign into iCloud during installation as that starts syncing everything to iCloud and you might not want that.
  • I moved over some files manually from a Time Machine external disk and they got “locked” i.e. I had to enter the admin password for any change to them. This is how I “unlocked” them: xattr -c -r FOLDER_WITH_LOCKED_ITEMS/ && chmod -RN FOLDER_WITH_LOCKED_ITEMS/

System configuration:

  • First off, update to the latest version of OS X, since every major update overwrites some system configuration and you don’t want to duplicate your work.
  • Turn on auto updates. Doh.
  • Go through all System preferences panes and see what works for you. Take your time to see what’s there, it pays off.
  • I disabled Location services, because I use VPNs a lot and then Location Services get totally confused.
  • Enable sending/receiving SMS and calls on OS X — a killer Apple feature for me.
  • Disabled Document Handoff because I don’t want all my docs in the cloud by default.
  • On a MacBook 12″ moving the Dock to the right makes the most sense in my eyes.
  • Set a nice “return for reward” message to be displayed on Locked screen. Something along the lines of “If you have found this laptop, please call me on MY NUMBER or send me an email to MY EMAIL and get a sweet reward! Thanks!”
  • Check Require an administrator password to access system-wide preferences. Doh.
  • Turn on FileVault and Firewall. Double-doh.
  • Firewall -> Advanced -> enable Stealth Mode. Though need to remember to turn it off when diagnosing network problems.

Finder preferences:

  • Show extensions.
  • When performing a search: Search the Current Folder, otherwise it searches the entire computer by default and almost kills Finder.
  • New Finder windows show: my home folder. I hate the “All My Files” default view. Absolutely hate it.

Various tools and apps:

  • Resilio Sync: fantastic app for sharing files among team members, based on bittorrent.
  • Slack: team communication, we use it religiously.
  • Crypho: secure team communication. I’m looking forward to the day when we can replace Slack with Crypho, so we have all communication secure, but as it is, Slack is just way more convenient for everyone to use.
  • LittleSnitch: allow/disable connections per app/port/protocol/address. Fantastic to prevent apps from contacting ads/tracking services and getting more insight into what goes on in the background.
  • Alfred: great productivity app, “replaces” Spotlight and then some!
  • Bartender: get that Menu Bar under control!
  • Flux: same as Redshift on Linux, adjusts screen colours for late night hacking sessions.
  • AppTrap: automatic cleanup of files that apps leave laying around after you delete them
  • iStat menus: to always be able to see what my system is doing with a glance.screen-shot-2016-10-05-at-20-44-24
  • Seashore: GIMP/Photoshop clone with a Mac-style UI. But seems an abandoned project, need to find a replacement …
  • Calibre: eBook management.
  • iBank: keeping my finances in check.
  • LibreOffice. And removed Apple’s Numbers & Pages.

Development environment:

  • Homebrew: the quintessential package manager for OS X.
  • Twitter: funny as it sounds, but Twitter is a great way to stay on top of latest patches/releases/news in tech.
  • Colloquy: a lot of Open Source still happens on IRC and this is how I keep in touch.
  • Chrome: been using it a few years now for browsing and development, but I want to switch back to Firefox soon. Extensions I cannot live without: BackStop, The Great Suspender, Send to Kindle, StayFocusd and Full Page Screen Capture.
  • Tunnelblick: the OS X OpenVPN client.
  • ExtFS for Mac: so I am able to mount ExtFS volumes (Linux drives, Raspberry PI SD cards, etc.)
  • pgAdmin3 and pgweb: admin interfaces for PostgreSQL, lately pgweb sees way more usage than pgAdmin3. Also sqlite browser for SQLite.
  • dotfiles: I keep a private git repo with all my “dotfiles” so history is tracked.
  • travis-cli & heroku-cli: working with Travis and Heroku from the comfort of the terminal window.
  • Vagrant: for simple virtualization needs, when I want to test out something without polluting my main environment.
  • Shush: a vital tool for any remote worker, to keep unwanted background noise from polluting teleconferencing.
  • Sublime Text: I’ve been a TextMate user for quite a while but I jumped ship when I saw how much faster ST is. That was years ago and I’m sticking with ST for now, got used to it and it works for me. I did migrate to ST3 recently though. The list of plugins I use:
    • GitGutter
    • SideBar Enhancements
    • Requirements Txt
    • Color Highlighter
    • CSS3
    • jQuery
    • SublimeLinter
    • SublimeLinter-annotations
    • SublimeLinter-pydocstyle (sudo pip2/3 install pydocstyle)
    • SublimeLinter-flake8 (sudo pip2/3 install flake8)
    • SublimeLinter-jshint (npm install -g jshint)
    • SublimeLinter-shellcheck (brew install shellcheck)
    • SublimeLinter-pyyaml (sudo pip3 install pyyaml)
    • SublimeLinter-json
    • BracketHighlighter
    • Jedi – Python Autocompletion
    • theme: SoDaReloaded Light.sublime-theme
    • pdb snippet: https://gist.github.com/phalt/72117041fbb7cf4c4697
    • starting ST from the current dir in console by typing subl -n .: https://www.sublimetext.com/docs/2/osx_command_line.html
Share on Facebook8Share on LinkedIn0Tweet about this on Twitter

Writing The Docs – Prague 2016

Share on Facebook0Share on LinkedIn0Tweet about this on Twitter

On September 19th and 20th Write the Docs Meeting took place in Prague. This year I had the pleasure to attend. More than 250 people came which is about 40% more compared to last year.  On my surprise the majority of the people were actual tech writers or ‘documentarians’ as they called themselves (well there were several talks were they pointed out that they actually don’t have a good, recognisable name).

All of the speakers were tech writers so there wasn’t much correlation with the actual coding or development from the software point of view. Nonetheless there were quite a few tips that I have picked up.

One of the first talks that I found interesting was about writing as a non-native speaker (by Szabó István Zoltán aka Steve). Although his main focus was on language differences and how they affect non-native speaker when he needs to write something (e.g. documentation) he also gave a few tips on how to write in generally. He said you should “Write drunk; edit sober” which I think is a very interesting idea (unfortunately I’m not drunk while writing this). The more technical suggestions were: First do the writing part and then the editing part. In the writing part you should:

  1. Create the structure,
  2. estimate the word number
  3. focus on the flow, don’t mind the grammar.

And in the editing part you should:

  1. Self-edit,
  2. grammar checkers,
  3. read out loud,
  4. send to the editor.

He also suggested in order to improve your language skills you should start writing your own blog, attend IRL events / conferences and of course read lots of books.

Another interesting talk was about screenshots. Apparently there are some people who can’t create proper screenshots so tech writers must do them themselves. He suggested that we should have screenshot policy style guide which I think is actually a good idea.

There was also one talk about documentation quality and what actually documentation quality is. We have structural and functional quality. Structural is about grammar, style, navigation, etc. Functional quality answers the following questions:

  1. Does it do what it’s supposed to do?
  2. Does it satisfy requirements?
  3. Achieve what it sets out to achieve for users?

Functional quality brings value and this should be our goal. Our goal as a technical writer shouldn’t be that our text is full with nice words that makes average reader harder to understand. It should be plain and simple so that it transports the information as quickly as possible. We should be avare that every sentence has a “user journey” so when you read a sentence your brain actually needs to interpret its information. And the more complex the sentence is the harder is for our brains to do that. We usually label this as “light” (e.g. comics) and “heavy” (e.g. Tolstoy, War and Peace) reading. Let us look at this sentence: “The defendant examined by the lawyer was unreliable”. When we read this sentence we first think that the defendant was doing the examination but then after we read the whole sentence our brain realizes that actually the lawyer was doing the examination. This is called “temporal ambiguity”.

The last talk I want to mention is about (mental) checklists. I found this talk interesting because people (including me) often confuse checklist with todo list. But they are very different. Checklists contains tasks that are repeatable. Checklists are used on a daily basis in a lot of industries. E.g. when airplane pilot takes off or lands a plane he uses checklist to check if he did everything he is suppose to do before taking off or landing.

We have 2 types of checklists: Read-do and do-confirm. They are pretty self explanatory so I will not discuss the differences here. One of the things about checklists we should always have in mind is that if we are using them we should keep them up to date. One of the worst thing that could happen to a checklist is that it contains incorrect items and that in the current process we are actually checking for different things (because we found a better way of doing things but we didn’t update the checklist). That is why I still prefer automatization over checklists (e.g. when deploying, I prefer to use TravisCI).


To wrap up this post I would like to mention a comment that someone (unfortunately I don’t remember his name) on the conference said about github projects. He said that when you are looking at some github project one of the most important things about that project is README file. Then we discussed how many README files are incomplete and/or not updated. In fact every user that opens a github project will first look at README file and if he doesn’t see it there is little chance that he will actually look into the sourcecode (you know this is true).


So to help you out, here is a nice README.rst template that you can use for your projects:


$project will solve your problem of where to start with documentation,
by providing a basic explanation of how to do it easily.

Look how easy it is to use:

    import project
    # Get your stuff done


- Be awesome
- Make things faster


Install $project by running:

    install project


- Issue Tracker: github.com/$project/$project/issues
- Source Code: github.com/$project/$project


If you are having issues, please let us know.
We have a mailing list located at: [email protected]


The project is licensed under the BSD license.


And if you want to read more about writing documentation this is a good place to start. I must warn you that if you choose the blue pillow there is a high chance that you will start writing better documentation :).

Share on Facebook0Share on LinkedIn0Tweet about this on Twitter

WP Meetups

Share on Facebook0Share on LinkedIn0Tweet about this on Twitter

A few months back I noticed we actually have regular WordPress Meetups in Ljubljana, our base town. We attended one in April, where David talked about theming and Emanuel about bringing WordPress into the Public Sector. On the second one, in June, we were active participants: Janez and myself delivered a talk titled Lessons learned running 25k WordPress blogs describing how we scaled Easy Blog Networks to 25k blogs running on several hundred servers.

Both events also had a Lightning Talks section, which is what I normally enjoy the most. So many great ideas packed into such a short timeframe. Looking forward to the next meetup that should happen sometime in Autumn!

img_8157 img_7930 img_7932vlcsnap-2016-09-11-11h59m58s941

Share on Facebook0Share on LinkedIn0Tweet about this on Twitter

Lessons learned from EuroPython 2016

Share on Facebook1Share on LinkedIn0Tweet about this on Twitter

This was my first EuroPython conference and I had high expectations because I heard a lot of good things about it. I must say that overall it didn’t let me down. I learned several new things and met a lot of new people. So lets dive straight into the most important lessons.

On Tuesday I attended “Effective Python for High-Performance Parallel Computing” training session by Michael McKerns. This was by far my favorite training session and I have learned a lot from it. Before Michael started with code examples and code analysis he emphasized two things:

  1. Do not assume what you hear/read/think. Time it and measure it.
  2. Stupid code is fast! Intelligent code is slow!

At this point I knew that the session is going to be amazing. He gave us a github link (https://github.com/mmckerns/tuthpc) where all examples with profiler results were located. He stressed out that we shouldn’t believe him and that we should test them ourselves (lesson #1).

I strongly suggest to clone his github repo (https://github.com/mmckerns/tuthpc) and test those examples yourself. Here are my quick notes (TL; DR):

  • always compile regular expressions
  • use local variables (true = True, local = GLOBAL)
  • if you know how many elements it will be in your list, create it with None elements and then fill it (L = [None] * N)
  • when inserting item on 0 index in a list use append then reverse (O(n) vs O(1))
  • use built-in functions, use built-in functions, use built-in functions!!! (they are written in C layer)
  • when extending list use .extend() and not +
  • searching in set (hash map) is a lot faster then searching in list (O(1) vs O(n))
  • constructing set is much slower then list so you usually don’t want to transform list into set and then search in it because it will be slower. But again you should test it
  • += doesn’t create new instance of an object so use this in loops
  • list comprehension is better than generator. for loop is better then generator and sometimes also than list comprehension (you should test it!)
  • importing is expensive (e.g. numpy is 0.1 sec)
  • switching between python arrays and numpy arrays is very expensive
  • if you start writing intelligente and complex code you should stop and rethink if there is more stupid way of achieving your goal (see lesson #2)
  • optimize the code you want to run in parallel. This is more important than to just run it in parallel.

Threading and multiprocessing:

  • you should always run analysis if/when threading/multiprocessing is faster. If you are using simple functions it will probably be slower
  • in parallel computing you need to catch and log errors
  • in parallel computing you always want your functions to return value
  • in parallel computing you never want your code to “die”. Always try to return reasonable default value even if an exception is raised. Slightly wrong is better than not getting an answer!
  • when using threading/multiprocessing use .map() and if you don’t care about the order use .imap_unordered(). It is the fastest because it returns the first available value.
  • if you have stop condition use .imap_unordered()
  • be aware of random module problems. Random seed gets copied to all processes. Result is “random doesn’t work”. You need to create random_seed function and ensure that you are in different random state.
  • is there any general rule when to use threads and when multiprocessing? Use threads if you have light jobs (i.e. they execute in 0-1 sec)

Another interesting talk was about code review (Another pair of eyes: Reviewing code well by Adam Dangoor). He pointed out that one of the most important things with the process of reviewing the code is to share knowledge. When you review others code you learn a lot especially if you take your time and try to really understand what he/she was trying to achieve. It is also recommended to always say something nice about the code especially when reviewing the code of junior developer. And when you think that the code you are reviewing has a bug, write a test that proves it.

EuroPython 2016 was really an amazing experience that every Python developer/scientist should experience. I’m really looking forward to EuroPython 2017!

Share on Facebook1Share on LinkedIn0Tweet about this on Twitter


Share on Facebook6Share on LinkedIn0Tweet about this on Twitter

Every time when I am in a pair-programming session and the other person does not use a clipboard manager I am taken aback at how such a thing is even possible. To me, a clipboard manager is such an essential piece of toolkit that I forget it’s there.

What is a clipboard manager? In its simplest form it’s a history of the things you copied. For example, you select text “Foo”, press Ctrl+C (Cmd+C on a Mac), then repeat the same on text “Bar”. The clipboard manager will keep both “Foo” and “Bar” values handy for use when needed.

Screen Shot 2016-06-21 at 23.15.17

My entire clipboard history, searchable, just one keypress away. Priceless.

Simple as that. And so, so effective! Every time you need to copy many things from one window to another, select and copy them one by one, go to the other window, paste them one by one. You save a ton of window switching and clicking around! Good clipboard managers support searching through the history of things you copied and they are smart about the type of content you copied, such as plain text, URLs, images, etc. There are many more reasons why using a clipboard manager makes your day easier.

Personally, I use the clipboard manager that comes with Alfred, the OS X productivity app. But there are literally hundreds of clipboard managers out there, for all major OSes and most of them do their job just fine. Choosing one is mostly about personal preference on keyboard for keyboard shortcuts and styling.

So, what are you waiting for? Get one!


Share on Facebook6Share on LinkedIn0Tweet about this on Twitter