3amOpsGuy

It's a brand new OS, it wouldn't matter if it was the best thing since sliced bread, I wouldn't be able to recommend full scale deployment at this point in the product's life.

It'll continue to rank behind Win7 for some time yet, but my point was its not massively behind Win7 as has been the storyline in the press.

The scope of this evaluation is to determine whether to avoid Win8 like the plague, or to tolerate its introduction (typically through new hardware acquisition).

Unfortunately in this instance, as if I hadn't backtracked enough from my initial statement, I won't be recommending the integration of Win8, however this has less to do with Win8 as a product than it does a whole slew of complex requirements around that company's IT needs.

I've been evaluating Win8 on behalf of an old client I still sometimes help out.

It's nowhere near as bad as the press has been making out. It's certainly different but I can point out a larger volume of improvements than the measly 3 obvious regressions.

I think you're confused about what problem indentation solves.

So one of perl's nicest features is it just plain, flat gets out of your way. If you want to write something some way, go ahead, perl will allow you.

This is great - you can cook something up in 5 lines that would take 15+ in Python and 50+ in C++. It also means that it's really tempting for some to abuse this ability, even for code which will be long lived.

Do we really need threads? From my limited Ruby experience, it'll happily fork new interpreters, it has connectivity with pretty much all major messaging queue implementations as well as various serialising and networking libraries. In short, talking to other processes is easy, even if they are a bit slower than threads (but if speed is such an issue, it's unlikely ruby would be your implementation language).

Threads only ever scale so far, when you need more processor cycles you'll have to go off-host eventually. By adopting a multi-process model with data shared over the network (with or without broker queue in between) you can benefit the app's ability to scale and its robustness greatly.

For the non-compute intensive reasons to parallelise, non-blocking code often performs better (e.g. chatty networking code) than threads anyway.

If threads aren't great (they aren't in Python), forget about them and move on. There are other tools in the toolbox, with the bonus that the other tools are actually better (in most if not all cases on unix like platforms).

Good question.

I found others i had to share code with weren't as interested as me about writing maintainable perl code - i got really fed up with a patch work of "write only" perl scripts performing useful functions in prod. From DB maintenance tasks to general housekeeping, to work-arounds for prod app issues that never got prioritised for strategic fixes.

I found in practice python code produced by most others was easier maintained: it seemed to more or less force people to write more readable and therefore, maintainable code.

I also viewed the fact that Python was one of the premier languages across so many problem domains (Systems, DB, GUI, Web, Large data, GPU, etc.) as being a sure fire payoff for any time invested in it.

In environments this size it's not any one persons actions dictate what becomes the status quo: different groups will have different agendas and therefore priorities and views. I guess i was lucky that everyone else was either willing to give Python a go, or was easily convinced.

FWIW over the past few years it's proven to be a good choice for us. There are still O'Reilly books float about, esp between the newcomers but there's no zealous "where's my camel book!" shouts anymore.

J, now there's a language! The C source is written in a J like style: a wall of ascii punctuation interspersed with single char identifiers.

It looks like a fantastically expressive language, but i fear the learning curve would be too steep for my time invested to pay off - others would have to spend the same time to learn it as well, negating any code sharing / reuse in my org (we don't use J).

Before i switched to Python as my general purpose language, i used to be a bit of a Perl fanatic.

I've still to come across a language that lets you get your ideas down as quickly. It's full of fantastic time savers, e.g. the for(<>) construct and the format output functionality cover a bunch of common use cases in minimal keystrokes (let me pipe in some data, analyse it, then spit it out in a clean report).

It can hurt readability but for small one offs, it often doesn't matter.

Landon Fuller is a great read, although not as active in the past year or 2. Have seen a few posts trickle through recently, as high caliber as ever.

change your email address with them to myoriginalusername+linkedin@whatever.com

Filter with gay abandon.

It offers a reduction in the time to get started; vagrant provides the wrapper script around vboxmanage that you would otherwise write & debug.

By effectively standardising that tool which many people would otherwise continually reinvent, the group as a whole benefits from sharing and moving things forward, e.g. The many pre-packaged system images, puppet config examples and the like.

If you're not using it, I don't think you'd be missing anything worth losing sleep over.

I looked into it a while back - I saw it as a potential way to save my time documenting our setup for others, but in the end I opted to make my own as we have other tools to be integrated with, and by doing it myself I didn't cost myself any extra time really. I would have had to adapt either vagrant or our machine provisioning setup which would have taken more time than writing a very thin wrapper over vboxmanage.

I'd be conscious about the LIPO battery choice & potential fire risk.

They're absolutely fine when treated with care (i've had many for years for RC planes & helis and never had more than minor issues), but i'd be concerned people are used to not having to care about their batteries.

If you discharge them below ~ 1.1v per cell (higher for cheaper ones) they don't quite explode but it's not a slow burn either: http://www.youtube.com/watch?v=hcwOwf55Rtc

There are other options like li-ion or, slightly lower voltage per cell but you can pretty much abuse them and they won't blow up: A-123's.

EDIT: for clarity, discharging to 1v alone shouldn't cause a fire, it's the act of charging them from that state.

When will we get a "programer's web browser"?

I mean a full blown browser of current generation abilities, but with the option of completely keyboard driven interaction. Concise input of small commands (navigation, data extraction, exploring and massaging of extracted data, data uploading etc.) that can be composed to form more complex interactions.

It should have full interoperability with the CLI, don't go re-inventing grep, sed etc. but instead stand on their shoulders by interoperating fluently with them. In practice i expect this means the "programer's browser" functions as a full blown terminal emulator too.

If it were a text editor (and it should be a competent one of those, but the web is more than a textual medium so some implementations should certainly offer richer functionality than plain text editing) then the net and its many protocols would be its filesystem.

It should be extensible, but only by 1 language. Competing programer's browsers could offer alternative extension languages as their differentiator.

It should be entirely open for extension, by that i mean more than plugins, i should be able to rip out core parts of it to be replaced with alternative implementations (A's needs won't match B's needs and so on).

It shouldn't go too far though, it shouldn't be a full blown operating system: why re-invent the wheel, reuse the thousands of man years effort in existing OS's. It should be multi platform.

We almost have the requisite component parts available now, who's going to get the ball rolling with the new wave of "programer's browsers"?

>> UX-archaic

Why then, in circa 40 years, have we still not managed to find a better alternative?

I can't help drawing parallels with windows / unix in the 90s and more so 00s. Yes, a point and click GUI is much easier to wing it with than a CLI, but, it doesn't deliver nearly as much power to the user as a proper CLI with a small number of reusable tools that can be composed to solve many problems.

To give a concrete example, if the GUI designer of your chosen deployment tool didn't imagine anyone would want to filter nodes to target a deployment by a substring of the node name, then you are out of luck - resorting to hacking your hosts file on windows to null route all the hosts you don't want to hit, followed by deploying to all nodes from the brain dead GUI.

With a proper CLI, only your imagination reduces your ability to solve whatever business problem (and they are infinite).

The net result of this shallow learning curve? We got a lot of people who refused to learn how to manage a network, winging it and being employed in positions of significance - average corp. with hopelessly leaky data safeguards and so on.

So back to the ux archaic editor, nothing has surpassed it despite 40 years of continual focus. While I wouldn't dismiss attempts to improve it out of hand (I'm a paid up customer of ST2), I also wouldn't count on an revolution relegating vim to the history books anytime soon.

As for VS, Idea etc. they are merely a chapter 11 filing away from being forgotten. Eclipse could live on. Who knows.

>> Emacs and VIM use has actually been going down since the 90s as a percentage of the developer community

My Google-Fu is coming up short, i can't corroborate this. Can you provide any links to data confirming this claim up?

I took a stab at getting some stats by searching stack overflow / server fault / super user for vim questions, emacs questions, textmate and sublime, vim comes out top by a long way, emacs next, the other 2 are a rounding error.

>> I'm surprised to be honest but maybe I'm missing something.

Give it a proper whirl, you'll never go back.

Proper python REPL history across sessions (not hacking up a substitute using a $PYTHONSTARTUP file to load readline history and register an at exit handler to dump history). History becomes as useful as a large shell history (i'm sure i did something similar last year, what was it?...)

In line charting, makes visualising any random thing (runtime of function, memory usage etc.) so easy you'll start doing it all the time.

The webserver notebook can stream line collaboration with co-workers. I like the ability to make "interactive documentation", although truth be told i haven't used this as much as i could yet.

IPython is extremely useful.

I like the qtconsole feature but i find it less than perfect to install:

1. pip install ipython 2. <system package manager> install qt4 3. pip install pyside / qt4 bindings

The better feature, for me anyway, is the notebook interface (it starts a local web server and gives you a rich web guy, somewhat like a Mathematica idea of interactive notebook editing with inline charting etc.)

But, that's a whole other bunch of dependencies that aren't in scope when installing ipython.

Not sure of the best fix, offer ipython and ipython-full-stack on PyPI?

Not sure if this helps but the Audi system, which I believe is exact the same on VW, Seat & Skoda, will park wrong side but only if you indicate into the side the spaces are on when approaching.

Only mention this because it wasn't documented in my manual and the sales folks had no idea.

In practice i find it's too slow to use, doesn't account for high kerbs with its preprogrammed trajectory (not user adjustable), happily dry steers and can be fooled by a squinty parked car in front of the space. Not a fan yet, but has potential, and if it means ill come back to less dings on the bumpers I'm all for mandating its use ;-)

A better system today is the Toyota reverse parking assist with guidelines overlaid which adjust to your trajectory based on current steering input and speed.

There's a code browsing view (window -> open perspective -> browsing) but i never use it.

For me i only need the following to zip through a sizeable code base with just a few key combos in eclipse:

* F3 - go to definition of thing under cursor

* ctrl+g - search for all usages of thing under cursor (used sparingly, too slow)

* ctrl-shift-t - find & open type

* ctrl-shift-r - find & open resource (these 2 should be merged!)

* ctrl-e + start typing the name of an open window to switch to it

* ctrl+shift+F4 i'm in too deep, close all open editors

* ctrl+/ fold all methods, i never warmed to ctrl+o or F4 for an overview of the code in a module / class

I have a couple of non standard bindings i set for things like show me the version control log for this file.

It all falls apart when you want to navigate within an editor a-la vim motions.

That's really hard to give a decent answer to. The answer really depends on the people involved in filtering the applications.

Can you mirror what the job advert lists it's looking for?

A bit more outlandishly, could you identify a person working in or near the position you're after, then google their CV to see what they listed?

For me personally (not that it should be used to base your decision at all) i've never distinguished between either.

Just for contrast someone i used to work with (an electronic and software engineering graduate) detested the idea of anyone without an engineer's charter (himself included until recently) referring to themselves or their education with the word "engineer". More than once he gave graduates a dressing down for using the E word... life's too short for that IMO.

>> As for the numbers, only to be expected in a hype game.

> What does that even mean?

Think dot com bubble, think real estate pre-2008, or more currently think zinga, Facebook, instagram. These things were MASSIVE before they died (or are about to die) a death. Most people didn't want to think they would fall as much or as badly as they did (or are about to) in the end.

They all share one thing, they're massively over hyped for the actual value they give. NB: that's not the same as saying they give no value. Each of the above have considerable merit, but nothing approaching their hype. History tells us the safest bet here is to cash out.

>> Think about something like the parts market for appliances and cars.

Let's say i'm an appliance manufacturer, or i'm a 3rd party parts manufacturer. Where is the benefit to me in any of this?

Will a 3D printer ever be cheaper or able to crank out volumes akin to my sub contracted production lines in China? I think we can safely say no.

3D printers are a niche, that's their value proposition. I can have an amateur knock out a part that's no longer made. The same way i can take a trip to a local metal worker with both parts of a rusted-in-half fender and say "hey, can you knock me up one of these for my 1963 jaguar e-type?"

3D printers will continue to be as relevant to Joe Punter as my local metal worker's English Wheeling Machine.

Random question for someone way more experienced with this than me...!

With Bootstrap i've never figured out, am i supposed to hack the bootstrap less directly or am i supposed to treat bootstrap as a vendor library and craft my styles separately on top?

The latter seems to be the case, but can't be sure.

Also i've not seen a definitive list of what styles are available with a description of what they're used for, e.g. "jumbotron" appeared in a recent release of bootstrap but i wasn't sure where it could be used or what for.

I've been doing some experiments to improve recall of documentation.

So far i've learned a few seemingly effective techniques:

1) Occasionally construct some weird sentences, throw grammar out the window for a sentence (any longer doesn't work) and people will recall that whole section of the document, months, even years later. I have no idea why this is so effective, but i'd love to know.

2) State an assumption and have it missing the obvious consideration. Don't make it some intricate detail, it has to be in plain sight even for someone not familiar with the topic. Again, people recall these sections and are happy to suggest how you could improve the document.

3) Never tell anyone you're playing tricks like this, it completely loses its effectiveness when people know what you're doing with the slightly strange documents.

4) Test the recall of others frequently on your text. Probe them and figure out what's easy to remember and what's not. You can use this to tweak your documents for future.

5) Don't over use it. The goal doesn't have to be to have them remember everything, but it must allow them to remember where they found the information previously.

YMMV, but i'm blown away so far and i haven't seen anyone talking about this along similar lines yet. It all started after reading one too many psychology books.

But it's just a prototype, a demonstration. It's not in use anywhere, it's not certified, there's nothing to say it even works yet. Searching doesn't turn up anything to corroborate that it's in use right now.

As for the numbers, only to be expected in a hype game. To my mind in 10 years we'll look back and say 'do you remember 3D printers? How they were going to take over the world' sure there will likely be some design companies knocking out prototypes on them but Joe Punter won't have a 3D printer purchase on his shopping list this decade.

>> It's being used right now by manufacturers to make custom parts in things like jet engines.

That doesn't appear to be true? They've announced they're intending to do it, they've bought a company specialised in it which suggests they're serious.

I can't order a 3d printed fuel injector for my jet engine today?

My point still stands. This is all just hype right now with nothing to show for it.

Another poster made a good point that it's a cheaper, more versatile, home-sized equiv of a CNC router / lathe. Looking at it like that makes a lot of sense to me.

It drastically limits the scope of such devices though from the current hype.

I'm still sceptical of 3D printing. They're hyped so much with little to show for it - when did you last use something printed on a 3D printer?

This is a technology designed to bring affordable, easy manufacturing to your bedroom, it's been around for years now, supposedly widely deployed. Yet hardly anyone alive today has handled or used a product printed on one of these machines?

From what i've read, the plastics suitable for printing do not easily make viable "hard wearing" products - although i understand various techniques can be used to improve this to some degree.

The raw materials used are not cheap and there doesn't appear to be much scope for future cost reduction. Perhaps more worrying is the limited option to reuse existing materials.

Until i start seeing and using products of 3D printing, colour me unconvinced. I'm sitting this revolution out.

Contrived is a bit uncharitable. 5 year old hardware (which would be around the calibre of a Core Duo with 1Gb ram?) is still perfectly serviceable for your average office worker.

With Linux they have the choice to defer hw upgrade until it's justified for reasons other than 'we need to upgrade the OS and because the current hardware came with an OEM licence and so is not covered by any volume licencing deal that may be in place (without spending extra) its cheaper to buy a new PC with a Windows bundled than it is to just buy the software upgrade then the hardware when it's really needed'.

Haha :) I keep going back to X over SSH.

Out of VNC, RDP and NX, VNC is the lame duck.

Out of RDP & NX, both require extra software but RDP is more widely re-usable (virtual box, windows etc).

The bandwidth requirements aren't the problem with X these days - a 3G connection at under 1Mbps real world is fine for reasonable display sizes, it's the round trip latency is the killer. It's such a chatty protocol, but on a LAN / WiFi it's fine and works out of the box with... scratch that, you need to install XQuartz separately since Mountain Lion. I almost forgot about that.

Run Firefox on the server and export the display over the network to the weedy laptop.

Depending on the technology used, exporting sound can be an hour of fiddling about to get it setup first time around.

It's likely the parent has listed this way for brevity of the post, while still trying to show the potential for complexity, which I believe is the key point here and i would agree with it.

The dict-as-a-switch expression is common to python, but it can be masked as the parent has shown in larger examples.

I have no idea how we could apply static analysis techniques to a construct like this. To be honest I tend to avoid this approach on readability grounds. It could be cleaned up with a dict subclass but I think inlining the dict call mechanics is simpler to read, even if it produces larger code, leads to repetition and couples you to this approach (which would be a strong consideration in the case of writing a library - where this type of code is most prevelant).