radeksimko

[radeksimko]

Re: Why I hate virtualenv and pip

Someone shared a link on Twitter to this article from 2013:

https://pythonrants.wordpress.com/2013/12/06/why-i-hate-virtualenv-and-pip/

and I wanted to comment on that, which then turned into somewhat longer reaction, so I'm writing this article.

Most are fair points, Python packaging is far away from perfect and any good Python programmer won't try to convince you that it is perfect.

The truth is though, that it's not worse than packaging in Ruby (Bundler), NodeJS (NPM) nor PHP (Pear, PECL, Composer) nor Go. The same applies to environment isolation, where NodeJS, PHP, Go have basically no proper solution and the hack called RVM for Ruby? Well, it kinda works, but I'll better be using Virtualenv if I'm supposed to choose between these.

There's no reason to point to Python and say that it's Python's problem, it's generally a problem across most languages and yes, LXC is trying to solve it across all languages.

Also, author should realise there wasn't LXC or it definitely wasn't part of almost every Linux kernel, so it definitely wasn't as easily adoptable as it is now in 2015, when we've got Docker and Rocket on the way.

I don't want defend Python or other languages that do things the way they do or pretend that there's no problem. There is a problem, but it isn't about Pip nor Virtualenv, the problem is much broader.

More importantly, I think that people like Ian Bicking and others who contributed to the Python ecosystem and at least moved it a bit further and brought a decent solution at that time (2007) deserve respect.

These guys IMO definitely deserve much more respect than author of that article.

Remember these words when you gonna be whining about LXC in 2025 or later and writing hate-articles about Docker or Rocket and saying that there's is much more better solution. ;-)

[radeksimko]

Scalability is not (only) about computational power

When it comes to scalability, most people think that it's all about HA systems, oversized machines (or cloud instances) etc. In general, they just think about the whole scalability issue in technical manner.

Well, it is technical but from my point of view scalability is more about how you can scale as the whole company and company is not created just from computers, but also people.

Company pays money to programmers, therefore it is crucial for any company to use programmer's time as effectively as possible. It is crucial for any company to increase the long-term value of the whole company (or its product) while using the human power of programmers.

What do I mean?

How long does it take a new programmer to understand your codebase in order to make changes effectively?

Does it take weeks, months, or even years? You're probably doing good job if it takes just days.

Programmers usually spend more time on reading (understanding) the code then writing it, that's just the fact, but you can still decrease that amount of time needed to understanding the code.

This is not a definitive list, but it is the list of my recommendations coming from few years of my programming experience:

1. Do Code Reviews

There's just no better way of getting know each other's code than doing code reviews. There's much more (advantages) behind code reviews, which would be for separate article.

In fact, two persons (author + reviewer) knowing any specific piece of code is always better than just one (author). Ideally, you can even find a bug or performance issue before it even reaches any user testing phase.

And - what's more important - when there are two different opinions (between author & reviewer), these guys will have to find compromise, which will most probably help any third guy to understand the code easily and it will help both guys to learn from each other.

2. Define Coding Standards

Coding standards doesn't need to be any sign of large corporation or European Union, where you need everything to be standardised. It may help all members of your team, even you and even the future members.

It actually helps you to become one team instead of bunch of individuals. It is obviously important to find a consensus and ensure that the majority of your team agree with the definition of standards and again, it is not necessary to standardise everything.

You can start with just couple rules, eg. where to put braces, how many (if any) spaces to put around which keyword etc.

When you write down this list, it is also good to have tools in place which will help all developers easily check whether the new code is compliant with these standards.

3. Choose a “good” framework

At first, it is really useful to use an open-source framework. Unless you're Google or someone, who anyway probably already tried to use all available open-source solutions, only then you may think about building your own framework (actually you should have a really good reason even if you're in that situation).

Why? You save time (= money) and headaches of your development team. Why? Because someone else in the community already covered the most use-cases. Why? Because you can scale up by just using existing code somewhere in the community. Why? Ehh...

Why on earth would you like to spend money on reinventing the wheel? There's probably no reason, but still so many companies are reinventing the wheel (or actually trying to do so).

What's the conclusion? Choose a framework which is well extendible and have active community.

4. Write the Clean Code

This would be for a whole new article or even more articles, but to make the long story short, just read the Clean Code.

Read it and encourage all other members of your team to do so as well.

This may sounds like an advertising, but this book has been written by programmers for programmers. These guys created its own best-practices which helped them to increase readability of code = reduce the amount of time needed to understand the code by others = save money.

Be aware that others === yourself after couple months.

You would probably find the same things after couple years of coding, but here you can have all this available without having to make your own path with many fails on it.

5. ?

6. Profit!!!

[radeksimko]

Socialbakers (Prague) ✈ Zappit (London)

It is almost 3 years since I started working with Socialbakers. There were up-s and down-s (as in any other company), but all the time, I really loved it here and I learned a lot (on all of my 3 positions there). I enjoyed working in that environment and watched how Candytech with tens of people rapidly grew up in such a large and known company like Socialbakers with over 200 people and over thousand of clients over the whole globe. Many people there did (and still do) a great job.

What did I love at most as a developer?

quite a flat structure of the company (~3-4 levels consisting of developer, Scrum Master, Product Owner, management)

the variety of technologies they use in production (PostgreSQL, MongoDB, ElasticSearch, NodeJS, Redis, RabbitMQ and much more)

internal lectures and workshops for knowledge share across the whole dev team

build something really global for customers around the whole globe

dealing with timezones and being aware of that you have nothing like "the time when your customers are sleeping and you can have downtime"

If anything of above sounds like a challenge to you, send your CV over to Martin Homolka.

Anyway 3 years is a really long time and I love changes and challenges even more.

I got a chance to fulfil couple of my life goals:

to work abroad

to learn english more by speaking it on daily basis

and that's the type of offer I cannot just let pass through my fingers.

I'm joining guys from Zappit in the North London at the very beginning of May as a Senior Developer.

Why them? Because I see a great potential in NFC and QR and there's still a quite small amount of companies, which really build business up on that and that makes them almost unique.

Wish me luck. ;)

[radeksimko]

Shorten your e-mail signature! And then do it again!

In my work lifetime I had chance to communicate via e-mail with many people on many positions in many companies and I can certainly say, that the most often thing I see and hate is e-mail signatures. Not signatures in general, but the way most people use them. In your "offline" life, you use signature to sign some important paper, to make someone sure, that you understand correctly what's written on some piece of paper et cetera. Can you imagine, you would be signing an invoice or an agreement with something like this? > Radek Simko > Chief Important Officer > Very important company Inc. > Founded in 2009 > www.company.com > radek.simko@company.com > Phone: +420 723 123 456 > > Phone 2: +420 723 456 123 > > Phone 3: +420 223 123 456 > > Fax: +420 222 123 456 > Cool Company > 2nd floor > Cool St. 2433, 234 22 Prague > Czech Republic > Don't print this e-mail, think of the trees. > This email is confidential and is intended for the addressee(s) only. If you are not the named addressee you may not use it, copy it or disclose it to any other person. If you have received this message in error please contact [postmaster@company.com]. Any views or opinions presented are solely those of the originator and do not necessarily represent those of Cool Company plc or any of its affiliates. On the basis that you are the intended recipient, then receipt of this email by you represents your confirmation that you agree, or continue to agree, to be bound by our standard Terms and Conditions applicable to the transaction to which this email relates. If you require a copy (or a replacement copy) of the applicable standard Terms and Conditions please email your request by return. If you have received this as part of a direct marketing campaign in error and no longer wish to receive such material from Cool Company, please notify us by replying to this email. > Cool Company Ltd., Registered Address: 6 Holywood Blvd., Los Angeles 132 44, US. Registered in US 5563206 > ______________________________________________________________________ > This email has been scanned by the Symantec Email Security.cloud service. > For more information please visit http://www.symanteccloud.com > __________ > Information from ESET NOD32 Antivirus, version of virus signature database 2888 (20080220) > __________ > The message was checked by ESET NOD32 Antivirus. > http://www.eset.com Impossible? It has actually been copy&pasted and anonymized from few of e-mails I got. The times have changed in last few years only in the way, that people are not putting there animated GIFs, advertising to ICQ and large animated emoticons. Do you think signatures in e-mail communication are different from the offline one? Maybe a little. Anyway, I think there's really something wrong, when: - the signature is longer than the message itself - the signature is expressing the textual representation of information instead of linking to it (Hey, 2012! Hello, interactive links!) - is saying redundant information in different sentences - is saying something what is obvious (eg. your email address) - is saying useless stuff (antivirus notifications) You should consider this stuff even more carefully, if you're sending your e-mails to mailing list with tons of potential receivers. Thanks god, the Google's team at GMail have quite the same opinion like I have. Therefore, they are automatically hiding long signatures and saving me tons of minutes every day when I am going through my inbox. Unfortunately, not everybody have that clever e-mail app. So please, do us the favor and reduce all the junk in your e-mail signatures, which has been copy&pasted from somewhere else anyway and is described above. You'll increase the chance of reading your message and reduce the amount of time for reading the message.

[radeksimko]

5 mistakes when looking for a job or an employee

I had both chances to run and assist by interviews with developers and to be addressed by many HR agencies and other people, which have been offering me a job position. I am really not an *expert* in HR. Anyway I think I can sum up the __most common mistakes__ I see people doing when they're looking for a job or looking for employees. ## Both: Be on time, everywhere, every time It may sounds weird, but this is happening to me the most often from both sides. If you scheduled an interview on __4pm__, you should already be on site at __3:55pm__ (in case of f2f interview) or on quite place where __nobody can interrupt you__ (in case of phone interview). ## Candidates: If you cannot make it on time or at all, say it What's even more ignorant thing than the previous? If you schedule an interview and call back __an hour after__ the official beginning of the interview that you cannot come (for whatever reason). You deserve to be presented on some kind of blacklist for other companies, so they won't waste time with you at all. ## Candidates: Don't talk >a lot< The interview should not be monologue by your side. People want you to talk briefly and don't run away from the original topic. __Focus on what you think is important__ in your life or CV. Do not try to "impress" by talking deeply about everything. It could be easily boring. ## Candidates: Talk about who you ARE, not who you MAY be I've heard many times: > *I don't know this technology, but I can learn it very quickly* Obviously... If you like the company and want work for them, you would do anything to get the job and the company is aware of that fact. Rather just __say you don't know this or that__, it sounds more straightforward and in general better than trying to promise anything till you even get the job. ## Both: Salary should not be the 1st topic Good candidates will work for the company mostly because of anything else except money and visa versa. __HRs__, when your e-mail to the candidate starts with > *We can pay you $30k for ...* it is quite demotivating (no matter how high is the offered salary) for good candidates, because they will know __you don't care what they will do at their job__. It's obvious you just need anyone to fill the position, no matter who. __Candidates__, you should not talk about money until you're asked to do so. Again - the HR/company want you because of your skills/experience, not because of the money. More importantly, you can ask about less money than they would offer you. You can be asked to do it directly > *What's your salary expectations?* or indirectly > *Is there anything else you want to know?* Good HRs/companies always ask you directly at the end of the interview.