This appears to use the theoretical schedule, rather than real-time information. I live next to a busy tram line, and what I see through the window does not match what the site shows.
"VBB-Livekarte zeigt berechnete Positionen der Fahrzeuge zwischen zwei Stationen; falls kein Live-Fahrplan vorhanden, dann Position gemäß geplanten Fahrzeiten"
Translation:
It shows the calculated position of the vehicles between two stations. If there currently is no live data it shows according to schedule.
It goes beyond that in the Netherlands. A lot of bus lanes have their own traffic light system -- they have very small lights to show when they can go or stop. :)
For buses, there would be a normal traffic light controlling only a bus lane, usually labelled with the blue buses only sign. It's not very common, but I know a couple of cases in London.
I can confirm that. As a US software developer, I have pondered going to live and work in the Netherlands, and I've done some research. Their visa for knowledge migrants (kennismigrant visa) seems to be very easy to apply for and would pretty much apply to anyone who reads this site. You do have to find an employer willing to sponsor you though.
The Netherlands is vastly more friendlier to skilled migrants than the UK, which seems particularly xenophobic at the moment, and I think it provides a much friendlier experience than Germany. They have expat centers (http://www.hollandexpatcenter.com/ and http://www.iamsterdam.com/en/expatcenter) that were establish to help immigrants get established and figure out the rules, cultures, and customs of the Netherlands. I've been impressed.
They also incentivise skilled migration by providing a 30% tax scheme for anyone moving there from outside the Netherlands, where 30% of gross income is tax free for a longer period (I think it's 8 years).
I've even spent a couple months learning Dutch (gemakkelijk, maar de uitspraak is moeilijk), although that probably isn't necessary. I hear that English is almost universally spoken in the Netherlands.
I'd certainly be interested in hearing any tips you have. I have over 10 years of web development experience. No mobile app development experience yet, although I'd like to get into that.
I've spent some there and can confirm a few things:
- English is spoken by a lot of the Dutch (esp. in bigger cities it's almost everyone)
- The Dutch are friendly people and are generally happy to help a stranger
- 30% tax ruling is a boon in a place where the cost of living is high. Please do your calculations carefully before you consider moving to The Netherlands and ensure you have some clarity from your potential employer about the 30% tax ruling. Also remember that if you lose the 30% tax ruling, you (almost always) lose it for good.
- unlike the usa where the visa process treats you like a potential (or a convicted) criminal, the Dutch treat their guests well. I only have good things to say about the process of moving to The Netherlands.
- no amount of reading or watching videos will help you understand how the Dutch are, unless you live among them. They are straightforward, down to earth and a relaxed people.
If you have made up your mind to move to The Netherlands (please do your calculations on earnings vs cost of living before that!), let me know how I can contact you and I'll refer you to the employer who got me to move to Holland (if this prospect interests you).
I have researched the issue lightly, and am told that EU rules are particularly ...bothersome. Is it true that an EU company has to advertise for/and keep open a position for 3 months and show that none of the applicants met the requirements as compared to the non-EU applicant to be able to hire them?
You're probably complaining about the reliability of this map but it is actually often the case. In my district the buses frequently run the red lights.
Well, they don't actually follow streets. Looks like it's just the shortest distance between two stops, even if that goes right through a building or over water.
Works surprisingly well though, I only realized after a while.
I created a register-based VM named RCPU, for educational purposes. You can find it at https://github.com/ddfreyne/rcpu. It has most of what you’d expect from a register-based VM, and even has video output (rcpu-assemble samples/video.rcs and then rcpu-emulate the resulting file with --video).
I have been using sublime-markdown-extended (https://github.com/jonschlinkert/sublime-markdown-extended), which has the nice feature of recognising and highlighting frontmatter blocks. Would love to see frontmatter support in the MarkdownEditing package as well!
The analogy given in the article is pretty accurate. The Smalltalk environment is unique in that it allows very easy access to the libraries, the IDE and the language’s internals (including the compiler!). The Smalltalk debuggers are among the best ones I have ever used.
(I’m mostly speaking out of my experience with VisualWorks, a commercial Smalltalk implementation, but other implementations are similar.)
I would greatly recommend everyone to give Smalltalk a try. The IDEs are pretty ugly and cumbersome, but don’t let that put you off. Get a feeling of the minimalism of the programming language and the pure form of object orientation. Dig through the code of the standard library — it’s quite easy — and check out the implementations of TrueClass, FalseClass, BlockClosure etc.
Unfortunately, many parts of the Smalltalk IDEs are horribly outdated and make Smalltalk a very poor choice of environment to use for production code.
Smalltalk lives in its own little world, and the tools that you’d normally use during day-to-day development are integrated in the IDE, and there is virtually no possibility of using external tools. The text editors are pretty bad, and you can’t use vim or emacs or Sublime Text. The Smalltalk VCSes are particularly horrible. For version control, you need to use systems such as Monticello or Store, both of which make me cringe just thinking about them again.
I also feel that Smalltalk coders get locked in into their environment. Many Smalltalkers that I have met are quite unfamiliar with what is happening in the outside world. Most of them have never heard of git, for example (and quite a few did not know what Subversion was). When an interesting technology enters the Smalltalk world, people seem to rush to reimplement it in Smalltalk (yes, there is STON — Smalltalk Object Notation).
These were the main reasons why I quit my Smalltalk job. A sad decision, but one that was unavoidable in the long run.
Smalltalk is a nice language and has IDEs with some very nice features that I would love to see in other environments, but it is also severely lagging behind in many other areas. I would like the Smalltalk community to be more aware of what is happening outside and build bridges. Without that mindset, I feel Smalltalk will simply fade out completely.
Source: I used to be a professional Smalltalker for almost three years.
With respect to version control systems, I notice you didn't mention ENVY. I can't comment on Monticello nor Store, never having used them, but I still miss ENVY. Best version control system I ever used.
Source: professional Smalltalker for about four years (fifteen years ago)
> many parts of the Smalltalk IDEs are horribly outdated
My opinion is the opposite: I find the IDE in Pharo to be simple and very elegant, far more human-friendly than any I've seen in 'mainstream' languages. And this version of Smalltalk is under heavy development, with a push towards even greater cohesion. This small corner of computing is seething with hot, cutting-edge activity.
> The text editors are pretty bad
Well, you ought to know that Smalltalk is focused on relatively small snippets of code, held together in consistent OO structures. There's hardly any point in fancy text-editing features when your methods are generally 8-12 lines long!
> Well, you ought to know that Smalltalk is focused on relatively small snippets of code, held together in consistent OO structures. There's hardly any point in fancy text-editing features when your methods are generally 8-12 lines long!
This! And also, in Pharo 3.0 there's being a huge push towards better text editing, although I've never ever needed more than what Pharo 1.0 did already provide...
Just because you have shorter methods does not mean you would not benefit from Emacs-like power. I use Haskell--which has even shorter functions, often half that length--and yet I still find Emacs exceptionally useful.
Any amount of text is still text, and Emacs excels at text editing.
I problem I ran into when giving it a try. I couldn't easily find a way to print to standard output. All I wanted was to print some strings, numbers and manipulate them. Instead, it was easier to have a red ball on the screen.
I believe it boils down to a matter of discipline.
If you say that you never randomly modify code in order to make it work (according to the tests), then that is great, and that is how every developer should work. However, my experience is that people who lack discipline (or face a looming deadline) tend to not take their time to properly reason about code and instead rely on the test suite to tell them whether code is right or not.
The title contains that "bold statement" to incite a response.
There are numerous fallacies in your article. I believe it's a misunderstanding of certain aspects.
> writing code in a test-driven way bypasses your brain and makes you not think properly about what you are doing.
You should not just start writing code blindly. You should have a clear understanding of the problem up front. When you start coding, it should be done after you have a plan.
> Furthermore, true 100% code coverage by tests is a myth: no matter how many good tests you write, not all cases will be covered.
Code coverage measures the code you've written tests for. It in no way promises to cover all cases. This is not a deficiency in code coverage, merely it's understanding.
> Therefore, mindlessly modifying code until all tests pass is likely to introduce new bugs for which no tests exist.
Ignoring the other parts of this that make no sense, I propose that mindlessly modifying code without tests will introduce bugs.
> Algorithms must be understood before being modified, and modifications must be done as if no tests exist at all.
I don't understand this. Of course they must be understood. TDD does not remove this requirement. I'm also not sure how modifications must be done as if no tests exist? Maybe you mean to suggest that optimizations in algorithms must be applied all at once, and cannot be made in small, incremental changes?
> You apply the optimisation, and some tests start failing.
Whereas if you did not have tests, you might not know this.
> But how can you be sure that the algorithm still works? How can you be sure that the mindless modifications did not introduce edge cases that were not tested before?
How can you be sure that your algorithm worked before in all cases? How can you be sure, without testing, that your changes still work?
You really are making a straw-man. You are effectively arguing that TDD doesn't prove something that TDD doesn't promise. In fact, your premise - "no matter which software development methods you use, do not forget to use your brain." - and your title imply clearly that TDD doesn't encourage using your brain.
That's most assuredly not true.
P.S. I hope I don't sound harsh. I'm not trying to belittle or insult you. =)
I have occasionally been tempted into the mindless code modifying that I described. That is in the past though!
More importantly, I have also seen this happen in professional environments. A very large test suite is very useful, but it is absolutely not a catch-all safety net.
