brunomlopes

For me, it's the portability/size.

I don't have a benchtop I can use just for soldering, so my soldering toolkit lives in a box with all it needs. When I wanna do some work, I pick up the box, open it, and most of the stuff gets used directly out of it.

I put a silicone mat on a table, pull out the copper scrub and iron holder, and work on whatever pcb. When it's done, I can pack it all in the box and store it.

A TS80 is portable enough to fit in the box. A full on station would be a bit harder.

On windows it's the same. Although I think I usually install ipython outside of virtualenvs, because I tend to always use it.

I'd like to propose another use case: HUDs.

I've recently took up cycling to work and back, and would love to have speed/gears/time up on the glasses, instead of having to look and focus down. Riding my scooter would also be better with it, since the speedometer and turning light indicators are a bit out of my normal field of vision.

Also, be able to see who's calling on the cell phone would be a plus (I've found that having the phone 'say' who's calling results in a jumble that I can't make heads or tails of, as most of the names are not English names)

I actually solved the "get the data out from the homebanking system" via 100 lines of javascript executed in phantomjs to screenscrape the site.

It isn't pretty, it might break, and I haven't looked into how to store the credentials "safely" (so it executes just when I call it and enter the u/p, and not in the background), but it beats the hell out of logging in and extracting the data by hand.

You might get some mileage of this, if you want to automate the data extraction and have an homebanking account.

Just to give my 2c, EF is not so much an alternative to Dapper/Massive/PetaPoco as an alternative to NHibernate.

Both are "heavy-duty" orms, while those 3 are more lightweight. My personal view is that for writes and maintaining a domain model, NH (or EF, but I prefer NH) is a good option, and when you need performance or just want a light layer to ease the mappings from sql to objects, micro-orms are the best option.

Mine doesn't crash on Web projects, but can't work for a couple of hours on a Windows Phone 7 project without it going boom.

I think most of it works fine and dandy, but some parts can be quite sensitive.

If you end up trying to setup git on a linux machine, two things:

- setup or have available another linux machine to act as a "client". git on windows with ssh can be a bit fidgety sometimes, and that would help you debug whether it's a client or server issue.

- do look at gitolite for managing the repos [1]. Its "simple" to install, and the features it brings to the table are awesome (from private 'scratch' repos to auth and key management, and several others).

[1] - https://github.com/sitaramc/gitolite#_quick_install

I used to struggle with it too, until some time ago I think it all kind of clicked in place.

Don't try and think of it as similar to other shells like bash, but as an interactive console for objects. The operators, flow mechanisms and semantics make a lot of sense from that perspective, at least to me.

I've found that in that capacity, and as soon as I grokked the object pipeline, it's a wonderful tool with access to the entire .net ecosystem and a really hard push from Microsoft to have support for it on most of their tools

I've been automating several procedures with it and it's been working great.

That said, I also have some (iron)python scripts for some other tasks that don't involve as much glue between applications and services.

Actually, if you look at other posts from Sam mentioning dapper you'll find that they profiled the site and found some bottlenecks also on the translator from the datareader to objects on linq2sql. Since they're going to hand-write the sql then they're going to take advantage of that really fast microorm instead of sticking with l2q.

I think you're on to something with "only one member is virtual" and previous experience.

Communication is essencial and harder to manage if just one member is virtual. So, it may not be worthwhile to manage just that one member differently, hence the requirment for "on-site" programming.

Interesting, and it makes a bit of sense, even if it is counterintuitive.

"It creates a single file system that spans the internal storage and the SD card." - Meaning that you don't worry about "shall I store this photo in the phone or in the card" and juggle disk space around after upgrading the memory.

Meh, ClassMaps for 90% of the stuff are all the same, so I love the automap ideia mostly to spare me the bother :)

Actually, if your model has ProductID and NewPrice you can create just the Update controler/view for that. Put some validation on the model, and the scaffolding is done.

Or you could write the form itself with the "EditorFor" helper methods, either for the whole class or for each field. It's not perfect, but good enough for a quick prototype or first version.

As for point 2., I think you can generate the UI from any model class, right? So you can create a model for each task and generate the scaffolding for that particular model.

Just to offer a different road, you could do something like that with the previous version of MVC + Fluent NHibernate with automapping and schema_update, if I'm not mistaken :)

I think you make a great point there about the teacher already knowing VB.NET and not knowing Python. It may be the difference between being able to teach the concepts well and show code to match and struggling with translating the concepts to "working" code.

I think there are a couple of idioms which are a bit more concise in ruby ( <something> unless <condition>, or some of the stuff with blocks), but it's a matter of personal taste, I think. I do agree on the "opaqueness", Python does tend more towards "runnable pseudocode" :)

I'd argue that Ruby is a bit harder to learn, specially for someone with no background in programming.

While Python tends towards clarity and predictability, Ruby tends more toward conciseness and power. That means some things are not as straightforward to figure out.

I've been using Git Extensions and it works great:http://code.google.com/p/gitextensions/

I find that the workflow using this tool fits me better than with tortoise, mostly because it is repo-centric, instead of working on the explorer.

Not only does that require reflection, it is very error prone and not refactor-friendly. Just change the type of the list, change the method, and it will blow up on runtime instead of compile time. In my opinion, that goes against the grain of Java (and c#, in a way) of having the compiler doing a lot of checking for you.

Google's approach, while more verbose, is a bit safer and more idiomatic.