- They finally found all those buried Atari cartridges, and confirmed a beloved urban legend. Just wonderful.
- This episode of @ExtraCreditz follows up an idea I always had about education. The key is being demanding, but allowing a lot of opportunities.
- Amazing book introduction, showing how no one is immune to think that they are stupid. Lots of things in live are hard.
- Readability in code is not about being literary. Is about making the code easy to understand. You don’t read code, you explore it.
- The Great Works of Software. The premise is extremely interesting. What are the most influential pieces of software?
- The hilarious (is funny because it’s true) Programming Sucks and a follow-up What programming is Like.
- Is programming a dead end job? I still can’t help but feel sad each time that a (good) developer decides to move into management.
- It’s easy to forget how much the things have changed in term of software distribution. What Writing and Selling Software Was Like in the 80′s (yep, also from The Codist. You should subscribe)
- The computer world is very dominated by English, and even so with latin alphabet. This idea about making a computer language in Arabic is fascinating. It not only shows how difficult is to set up an environment without problems out of “the ASCII world” (the magnitude is not comparable, but trying to code in languages like French or Spanish has a lot of friction), but it also shows up how alien (yet beautiful) a different alphabet looks. I wonder how code and programming will be if the dominant language would’ve been something like Chinese or Arabic.
- What is the “Agile mindset” anyway? The graph is very interesting. Specially the “Chaos labeled as Agile” side.
- I don’t really like the idea of “rivalry” against Vim and Emacs. I prefer to consider them two valid options. But this article goes into explaining their different appeals and why they have been around since an extremely long time ago in computer-years.
- 10 Most common Python mistakes. Good to check.
- Seven habits of effective text editing. A great essay by Bram Moolenaar (of Vim fame). It is applicable to any editor, but, of course, shows why Vim can be such a good choice (once you know how to use it, obviously)
- A useful collection of recipes in Python. Thirty python language features and tricks you may not know
- How to be a sane programmer. Basically, do other stuff not related to programming. The related Business Insider article is also worth the read.
- The Evolution of a Software Engineer
- D/A and A/D Digital Show and tell. Great explanation on how sampling and analog conversion works. I spent my college years dealing with this stuff (and using the same equipment), it is explained beautifully.
- 10 important URLs that every single Google user needs to know Interesting stuff about privacy and Google.
- A glass breaking recorded at high speed.
- How to Create an Awesome Candidate Experience. On thing that I particularly liked about it is the fact that it acknowledges how emotionally exhausting is to go through a recruitment process for the candidate.
- Game servers UDP vs TCP. great article about the differences between TCP and UDP, usually not well understood.
- Amazing precision. The art of Street Typography.
- I love this quote: “I do not want to be a “rock star”. I want to be a good engineer on a great engineering team“. I talked previously about this, and how a great team will be much more productive than a bunch of “Ninja Developers”.
- Some gifs showing Vim capabilities. Why I use Vim.
- More about the philosophies behind vim. Why Atom can’t replace vim.
- A browser game, similar to the great Threes for iOS, with a binary twist. 2048 It can be a little addictive, though.
- An this is another brilliant game. Create your own metro system. Mini Metro.
- 3 wrong ways of storing a password and some examples to do it in a more proper way. And more about setting a salted password hashing.
- Don’t be a technical masochist. It is good to have options and recognise best tools for the job.
- An article about the different issues (while mostly stating age on the title) that can be growing on the current “startup culture”. Maybe a little exaggerated in some aspects, but an interesting read nonetheless. Silicon Valley’s Youth Problem
- About Agile as a buzzword and getting back to the core of the Agile manifesto, two related articles: Agile is dead (Long Live Agility) and Agile is Dead: The Angry Developer Version. I write something related to this a while ago.
- Good tech lead, bad tech lead.
- Can we please please stop telling people that coding is easy?
- Confessions of an Intermediate Programmer. The perception and psychology of competence.
- The Science of Making your Story Memorable Some interesting advice about presentations. The presentation itself used as example is interesting as well.
- Thirty percent feedback to iterate faster.
- The classic “your problem with Vim is that you don’t grok vi” response in Stack Overflow.
- A very nice list of Python articles. Best Python 2013
- Companies and startups are different. Not only in size, but qualitatively. An startup is based on the search for a business model, while a company is based on the execution of a business model.
- A typewriter to print water paints. Amazing.
- How much is time wrong around the world, actually meaning how places in the world are synchronised to “12 AM when sun is higher”.
- A reflection about how Internet is so full of strong emotions and is so judgmental.
- When It’s your job to give bad news, because we don’t live in an ideal world.
- Writing is hard.
- This is a wonderful comment (in Hacker News)
- A great initiative to clean up Vim code. Neovim. It includes a fundraiser to help in the initial phase.
As a way of collecting interesting reads across the Internet, I plan to keep a relatively regular posts with some articles and posts that I’ve read, mostly related to development, software and tech world in general.
Here it goes the first edition.
- Your Progress As A Programmer Is All Up To You
- Theory and practice Short and simple, but nice
- Every line of code is always documented Nice ways to use version control to our advantage when navigating through unknown code
- When random isn’t random enough or why randomness is a more complicated problem than it looks
- Interesting talk about different databases and distributed queries
- A 1986 Bill Gates interview about coding. It is interesting how some of the topics are still challenges today, but have been more refined, like team collaboration. Love this quote “We’re no longer in the days where every program is super well crafted.”
- Why indie developers go insane, about (but not limited) to all the Flappy Bird issue
- Nice graphic representation of version control history. Using airplanes!
- gn command for Vim. This is a very interesting new addition to my Vim lexicon
- Very good points about non-English speakers developers. Not sure if I totally buy it, at the end tech world is so predominantly english, that being able to use it is a huge win, but still interesting read.
- Being a noob programer at 38
Hope you enjoy it!
There are a lot of discussion about how to make Vim “an IDE”. Vim is a great text editor, but when we are developing, there are lots of extra tools that are very useful. Code completion. Easy navigation through files and classes. Source control integration. Syntax checking. Navigation that understand the semantics. Integrated debugger.
My problem with IDEs (and I have used a few over the years) is that they give you a lot of support, but at the cost of increasing the complexity. They are slow for a lot of common operations and they use a lot of resources. Code completion, the good kind that will allow you to get the types of a method, not just finish your words (which most of the time is trivial), is useful when developing on a static language, but since I program in Python is something that I can’t find good use of it. I just don’t use all that stuff, so I don’t feel I can justify to pay the price.
Another problem with IDEs is that they tend to be designed, by default, to the newbie. That’s not necessarily a bad thing, Vim is a pretty intimidating tool because is totally crazy for the rookie. But it generates a bloated environment to start with. If you open Eclipse, a popular IDE (and one I’ve used for some years), you’ll get a relatively small frame for the code, and a lot of extra stuff surrounding it. Logs, file navigation, class definition, a huge toolbar, maybe even a TO DO list…
For example, think about file navigation. Sure, it’s useful to move around. But it is used only at certain points in time. Most of the time, it’s just used as an entry point to code, and then the navigation can be achieved, either just moving around in the same file, by a referral from the code (like going to a method definition), or just searching on the whole project. In case you need to go to an specific file, you can then show the navigation window, or even better, search by filename. That only happens during small periods of time, so the rest of the time the window is just wasted space on screen. The same thing happen for a task list. It is useful to know the next step. But not while you’re working in one task.
Hey, it is possible to hide the navigation window, and display it only at the proper moment, to save space. I have done that. But it’s not there by default, so most of the people I know just keep it open “just in case, giving context”. They just get used to it, and don’t perceive it as a problem, But having half of your screen full of information that is irrelevant 95% of the time is a huge price to pay. And certainly not a good use of an IDE. The good parts of an IDE are things like automatic compilation and deployment, refactoring tools (not just renaming), debugging, help with the types in static languages, automatic generation of code, etc. Not showing everything, all the time.
Vim is a text editor, but it is also sort of a philosophy. It is not about showing stuff, but about having stuff available at the right moment, with a quick command. It is not just about using hjkl to move around and having an insert mode. It’s about being precise. It is difficult at first, because you can’t simply discover what are the available options, but it also pays off in terms of focus and clean environment. When programming, the most important part is to keep as few things into mind as possible. Keeping all relevant information, which is already enough, but nothing more than can distract you for the task. It is also about doing one thing, and not a hundred. I use other tools for things like source control and debugging. After all, we have the whole OS to work as our IDE.
I use a small number of plugins in Vim. When you learn a little about it, you find out that it’s amazing the number of features and stuff that can be achieved “out of the box”, and how little extra is actually needed to have a really productive environment. It’s just that we need to move from the usual “browse through menus” world that most of software uses, and devout some time to, well, study and learn. It’s really worth it.
I am a Vim user. And a Vim fan.
I was fiddling around for some time, you know, just knowing the basics, because it is convenient to do small changes on servers without having to worry about installing anything. Just the basics, insert mode, some search, save,
and a couple more things. Then, around two years ago, I decided to give it a try as my main editor, after watching a presentation of a co-worker (my boss, actually) about how to use Vim (he has been using Vim for around 20 years)
At the beginning, it is quite difficult, to be honest. You have to relearn everything about editors. But I was doing OK after one or two weeks, so I kept using it. I was also forcing myself into improving my usage, reading about it and learning tricks…
Then, after a while of using it and read a lot of instructional material (I cannot recommend “Practical Vim” by Drew Neil strongly enough. It’s a FANTASTIC book), everything started to make sense. Let’s be serious, the problem with Vim is not exactly that is “difficult” per se, it’s that it is so alien to any other text edition experience, that you have to forget everything that you know about how to edit text. That’s why I don’t agree that the Vim learning curve is a myth. Because, when we first heard of Vim, we already have 10+ years of using things like Word, NotePad or Gmail to write text. We need time to assimilate how to edit text “the Vim way”. And that takes time to assimilate, as your muscular memory works against you.
And, yes, the Vim way is awesome. But it is awesome not for the reason that usually someone will think at the start. There is the perception that Vim is awesome because is fast. It is not.
Continuando el post que escribí el otro día acerca de los cachivaches que uso para trabajar, voy a hablar también un poco de el software que utilizo.