loupgaroublond

This is the bees knees of chat tools, but what's up with the gratuitous use of Twitter Bootstrap everywhere?

lzma takes long enough to compress suitably large files that it's not always ideal for operations. While CPU time is generally cheaper than storage space, archiving systems don't always have the most powerful chips in them and tend to favor the cheapest storage possible.

Nonsense. I've worked in an organisation where we trained our recruiter to ask simple weed out questions. We would use questions like 'what is an A record?'. The candidate must give a two sentence or less answer right away. The recruiter didn't really know what an A record was, but knew how to ask the question. This saved us so much time because he could filter out tons of bad candidates for us immediately, without even looking at resumes.

As for 'crisper' resumes ... this guy was a Santa Cruz hippie at heart. He knew what was up in the tech industry. If you pick your recruiters for having some personality, it makes your hiring process go so much better too.

PS - This is about Operations hires, there are similar tricks applicable to Engineering hires.

This is where having lots of experience comes in play. It's possible to hire lots of people, someone to operate the forklift, a geologist to evaluate the stones, a physicist to plot flight paths for the stones, etc.... but each hire will slow your startup down. Work with someone who has done a startup before, or get mentoring from that person. This will teach you to use the right tools at the right time before you end up in such a pinch.

The netherlands is a different beast when it comes to Geocoding since each postcode only corresponds with around 10 buildings all very close to each other. Most other systems cover larger delivery areas. My complete amateur comment is that you need different algorithms for different countries.

I would consider this very valid pre interview. It's a bit mean; ideally an assignment should take 15 minutes to do. The advantage is, if someone does it, does it well, you have a really good indicator if that person is a good fit.

I have also played with and had dual core android phones and the scrolling experience is nothing like iOS by any means. One of Steve Jobs skills is that he had an innate feel for good scrolling well beyond the feel of the average person. It might feel the same to you. You might be perfectly happy with an android. Still, android has a challenge to make the OS feel as snappy on a wider range of CPUs and platforms than iOS and the lack of of consistency, even on dual core machines is like night and day.

Oddly enough, there are no major parties in the US that are built on a platform of strong constitutional protection.

Let's see....

The skills you need to do IT aren't something you can really learn in school in any way shape or form. These include customer service skills, understanding the needs of a business intimately and learning how real business are run. The people that are passionate about doing IT in that context are far and few between. Since it's seen as a service job, it forces a lot of people into other disciplines after a couple of years behind the helldesk.

Many IT shops also fail at communication. There is a lot that we do behind the scenes and no IT shop i've been at is doing a decent job constantly reminding everyone why they are there. Organisations need to know what improvements IT is working on and how it will better serve their needs, and they need to get excited by it. People get excited when Apple introduces new technology, but they get less excited when suddenly they can log in everywhere with the same password. Market that better.

IT, Operations, DB and Co. will resent you for asking for things when they are already busy putting out fires, fulfilling all your other requests and being the whipping boys and girls of your organisation. Google is a notable exception because their IT department is far better managed than most. Make sure all your technical service departments are tightly aligned with the mission critical things in your org and make sure management is shielding them from requests that get in the way. The more focus the techs have on core things, the faster they get done and suddenly the more spare time they have to help you get your project done on time too. Time management and business planning is key here.

Finally quit this 'for the CEO' or 'for Alan' mentality. If someone's computer fails, it should be replaceable within a couple of hours. This special person who's making a larger salary than you should understand better than any one else, never be dependent on a single point of failure to run a business. This doesn't mean a CEO has to be a tech genius or your star programmer an IT genius. They should just be smart enough to ask their IT department ahead of time 'what do i do when my computer fails?'.

IDE's are a bit of a closed off garden, to use a bad metaphor. They provide all the components you need, editors, terminals, shortcuts to run commands, but when you learn that you can choose between using an IDE or building up a toolset on your own, then you can make a better choice for the job at hand. There are some really good IDEs out there and once you learn both, it's personal preference. I certainly use both depending on the task.

/bin and /sbin - binary files go here, namely programs /lib - all the shared libraries and other code that gets executed by programs /libexec - other kinds of executables that are not shared libraries or command line programs /src - source code /src/include - all your C headers /share - shared resources, data, game data, pictures, wallpaper, icons etc... /share/doc - documentation /var - runtime data, log files

So what's /usr? These resources get split between / and /usr for historical reasons. There's a push to put everything in /usr and get rid of the split. Go look it up if you want to know why it's this way.

The thing to notice here is there are no program specific directories at the top level. This is because all programs are thought of as small tools or cogs that you can build larger tools upon. It's a system, not a way to run a couple of different apps in their own sandbox.

Probably the most important thing to know coming from the Windows world is that in Unix (which includes Linux) is that the OS is the IDE. From the way the OS is set up, where and how libraries are stored on disk, how you install things, to using various editors, tools, the command line and compilers, it is an IDE.

When you work with a 'stack' or a runtime like Mono, Python, a JVM, many of these details are partially hidden from view. The same if you use an IDE like Eclipse or MonoDevelop.

The better you understand this, the more shallow the learning curve will be with any tool you use, even emacs or vi.

As for getting started, here's a few pointers. It doesn't matter which distro you use, it's 2011, they all work pretty well. Instead pick the one you're most comfortable with. Mint and Ubuntu are good contenders because they are both easy to use, and Mint is based on Ubuntu. Fedora is better if you absolutely must use cutting edge tech. Suse is great for giving you a shiny frontend, close to cutting edge tools and an integrated environment that's also developer friendly. Just pick one, if you like it, stick with it for six months.

The same goes for runtimes and frameworks. Pick one you like, because a friend recommended it. Try the tutorials. If you like it, and get along with the community behind it, play around with it for 3-6 months before moving on.

Most importantly, find a friend who's using Linux already. Don't pester that person too much with questions, but just chat at least once a week about it. Focus on what you did, what you like, what was difficult. Chances are, your friend will be able to tell you, 'oh, sure, you could just do Foo and get this result'. Part of the learning experience is a week of pain you don't forget, solving it on your own, and then learning that other people solved the same problem.

Most of it's been covered here, but another point is that for every mainstream language that doesn't seem to be so revolutionary, there are lots of little languages that never made it. In order for there to be lots of innovation, we also need lots of iterative steps in languages. This helps the less than genius programmer, the ones that get that templates in C++ are good, but would never bother learning lisp, get the new ideas in incremental steps.

Also, something you see quite a lot is innovative concepts built onto existing languages via libraries that then get integrated into new languages.

You're asking the wrong question. If someone could do it, they would have. Ask yourself why hasn't Craigslist been cracked. What does Craigslist not serve and how can you step through, via iterations, a product that's disruptive to how classifieds are done today.