It took me some twenty-plus years to really learn how to program. It wasn’t for a lack of trying either, it was just that I was trying the wrong way. I tried to learn to program by following tutorials that created programs I didn’t have the slightest interest in keeping. I was trying to learn for the sake of learning.
Now I’m sure that works for some people. Intellectually curious for the sake of it. I envy you. But that’s not how it worked for me and I know that’s not how it works for a lot of other people.
What made it click for me was programming in anger. Programming because I needed to. Programming because I gave a damn about what I was writing and I wanted it done sooner rather than later.
That’s how I learned to program Ruby. By making it my mission to write Basecamp in it. When you’re learning on a mission, the order of things come really naturally. So what exactly do I have to do to get this messages section working in Ruby? Oh, I’ll need to do a loop here. Oh, I’ll need to get something from the database there.
Before you know it, you’re half-way done with your idea and you’ve accidentally learned how to do it too.
In short, you start with little bit of something real and make it tick. Then you make it tock.
MapReduce is a framework for processing huge datasets on certain kinds of distributable problems using a large number of computers (nodes), collectively referred to as a cluster. Computational processing can occur on data stored either in a filesystem(unstructured) or within a database (structured).
I can say that I speak fluently vim. And there are not much hokeys and commands I have to remember .. Because some peoples think vim is difficult, I want to share with you the most important of these ..
o insert new line after cursor and enter insert-mode (almost all of my vim-sessions start with this ;)
i enter insert-mode
ESC quit insert-mode, go back to cmd-mode
v start visual-mode (this allows you to highlight text visually)
V the same, but highlight the whole current line
g jump the start of the document
G jump to the end of the document
x cut the highlighted text into vim-clipboard
d delete current line
p paste the text from vim-clipboard
. redo last step
> indentation right
< indentation left
/ enter search-mode
cmd + w -> up jump to a split-screen before
cmd + w -> down jump to a split-screen after
The most hotkeys works also in visual-mode (text is highlighted), this is especially important for the indentation-hotkeys.
And now some commands:
:set ai set auto-increment on
:set noai set auto-increment off
:set hlsearch highlight search-results
:s/search-regexp/replaceBy/g search and replace by regexp on current line
:%s/search-regexp/replaceBy/g search and replace by regexp in document
:a insert-mode for long text (quit with ESC or cmd+c)
:split split screen horizontal
:vsplit split screen vertical
Oh and .. not vim-specific, but with cmd+z you can suspend your current vim-session to background in the shell (to start a new session for example), and with the shell-command fg you can put your vim to foreground again. With fg [number] you can get a specific task, by passed number.
But beware: I used this feature in combination with screen for a long time excessive. I loved it. But there were times I had 20+ open tabs on screen and 30+ suspended vim-sessions in some of this tabs. It was the perfect chaos .. but as it took more and more time to find a specific session, I changed this work-flow. Today I mostly use eclipse (splited in 3-4 window-parts and 20+ editors in each of them ;) ), but I hate Eclipse and Netbeans for their slowness. I used also the Editor geany for a long time, but splitting windows is a must-have feature for me.
This means, if you can close you vim-sessions after you are done, it may boost your productivity. And if you have to work remote on a linux-server, this may be the best setting for you.
[..] The people who write and maintain these jokes are expressing and reifying hacker values. This is especially important for us, because our avenues of cultural transmission are in some ways quite restricted. We don’t have a material culture; we use and borrow the tangible artifacts of the culture(s) around us, but we don’t really have any of our own other than ephemera like T-shirts and mugs and a few toys from ThinkGeek. Nor do we have generational transmission in the normal sense; almost nobody gets to learn hacker folklore at a parent’s knee (although I know one exceptional family that comes close to this). [..]
Oh, what a great article describes the myths around hacker humor :)
For me, I got involved into this, at my first real job 10 years ago. I worked as a tech-support dude for linux-based webhosting-product and my chiefs and most of my colleagues had this sense of hacker-humor. So my opinion is, instead of being involved by parents (which would be great :D) or from the internet in this sense of humor, it is important to have colleagues with this techie- and hacker-humor.
And fyi, maybe not surprising, my favorite is RFC 3092
“From a bit to a few hundred megabytes, from a microsecond to a half an hour of computing confronts us with completely baffling ratio of 10⁹! The programmer is in the unique position that his is the only discipline and profession in which such a gigantic ratio, which totally baffles our imagination, has to be bridged by a single technology. He has to be able to think in terms of conceptual hierarchies that are much deeper than a single mind ever needed to face before.”—E.W. Dijkstra
Software engineering as it’s taught in universities simply doesn’t work. It doesn’t produce software systems of high quality, and it doesn’t produce them for low cost. Sometimes, even when practiced rigorously, it doesn’t produce systems at all.
That’s odd, because in every other field, the term “engineering” is reserved for methods that work.
What then, does real software engineering look like? How can we consistently deliver high-quality systems to our customers and employers in a timely fashion and for a reasonable cost? In this session, we’ll discuss where software engineering went wrong, and build the case that disciplined Agile methods, far from being “anti-engineering” (as they are often described), actually represent the best of engineering principles applied to the task of software development.
I’ve been hacking instead of writing during my spare time the last couple months. The result is a streamlined console application for exploring web services and web sites. It’s something of a cross between curl and the Lynx browser.
The Year 10,000 problem (also known as the Y10K problem or the deca-millennium bug) is the class of all potential software bugs that would emerge when the need to express years with five digits arises. The problem can have discernible effects today, but is also sometimes mentioned for humorous effect. (via Ian)
“Where I can see the comparison between Art and Programming failing is when a programmer is using a high level language or using an API or for example Ruby on Rails. If you really want to call yourself a software “artist”, you should go back to the old traditions—draw your own fonts, draw your own “windows”.”—
Today, with the availability of large multi-core and large memory systems, there are more cases where you might have a single machine that can cover your scalability and performance goals. And yet, there are several other factors to consider when choosing between the two options: