Normalerweise hat fast jede Sache (SW, Tutorial, Doku, …) einen Hacken, weshalb ich sie nicht uneingeschränkt weiter empfehlen und loben kann. Anders bei Michael Hartl’s Ruby on Rails Tutorial, Ruby 2.0, RoR 4.0, Git und Heroku.
Ich habe zwar eine lange Erfahrung mit vielen Programier-, Script- und Metasprachen, aber seit ich es beruflich nicht mehr benötige, komme ich selten dazu, mich einem Projekt zu widmen. Ruby hat mich vom Anfang an fasziniert und von Rails war ich begeistert, aber ich hatte nie die Geduld es wirklich zu erlernen. Ruby hat mich wegen seiner konsequenten OO fasziniert und es ist eben keine Sprache, die aus dem strukturierten (prozeduralen) Paradigma heraus entstanden ist und somit den ganzen Müll nicht mitschleppte. Müll meine ich nur hinsichtlich der Entwicklung, denn es gibt viele Nnicht-OO-Programiersprachen, die alles andere als Müll sind. Erwähne hier nur Assemmbler, C, Cobol ….
Aber bei einer OO-Sprache war der Neuanfang von Matz von Vorteil. Ok, Java hatte auch einen Neuanfang und ich kenne es seit dem Anfang, obwohl damals meine Programmier-Lehrer von einer temporären Modeerscheinung sprachen. Trotzdem mag ich es einfach nicht. Nicht nur, weil das erste Beispiel, das ich auf einem, damals modernen 486er HP-Laptop kompilierte zirka 20 Minuten zum Starten brauchte (da konnte man sehr viele cups of coffee trinken), sondern es hat mir einfach alles zu viel Overhead. Für das Betriebssystem benötigte ich damals 1,4 MB und die Entwicklungsumgebung alleine war schon um ein zig-faches größer. Wie dem auch sei, es gibt Programmiersprachen, die ich einiger maßen kann, solche die ich mag, solche die ich nicht mag und natürlich auch solche die ich nicht einmal kenne. Aber um die wird es mir hier kaum gehen. Ruby und Rails kann ich noch immer nicht, obwohl ich schon einiges darin programmierte und mehrere Bücher dazu las. Irgendwann habe ich es aufgegeben und meine letzten Versuche startete mit Ruby 1.7 und Rails 2.x
Vorige Woche stolperte ich über Michael Hartl’s Ruby on Rails Tutorial und nun bin ich wirklich begeistert. Da funktioniert einfach alles und es ist so verständlich geschrieben, dass sogar ich es verstehe. Ich habe es zwar schon komplett durchgearbeitet, aber ich werde es mir nun aus Dankbarkeit auch kaufen. Es ist wirklich sehr gut und ich kann es Anfängern in Ruby on Rails uneingeschränkt und mit bestem Gewissen empfehlen. Danke an Michael Hartl.
Schlagwort-Archive: Tutorial
Testing Practices Interview 7: Mike Gunderloy
The Testing Practices Interview series is back. Our interviewee is Mike Gunderloy, publisher of A Fresh Cup and member of the Rails Documentation Team.
Mike has recently released Rails Rescue Handbook, a guide to taking over Rails projects that have been abandoned or are otherwise new to you. It’s a DRM-free PDF file, available for $9.95, and it’s full of useful tips and advice, highly recommended.
So, here’s Mike.
How did you get into writing tests regularly? Did you have a specific moment when you realized automated testing was valuable?
To some extent I’ve been testing for 30 years, ever since I got started programming. I don’t see a strong distinction in purpose between manual testing, debugging, and automated testing: they’re all ways to make sure your code does what you think it does.
As far as automated testing, though, my first exposure was during some Microsoft contracts 10 years ago or thereabouts. But on those big projects, automated tests were maintained by the testers, not by the developers; completely different group of people and tools. I did dabble a bit with tools like TestDriven.NET, but ultimately, it was moving over to Ruby/Rails that got me into a truly test-infected environment.
So I’ve pretty much “always” known that testing was valuable, and even seen the benefits of automated testing for quite a long while. It’s been an evolutionary step from there to developer-written automated tests and TDD – which I am not religious about. I use TDD when it suits me, and skip it when it doesn’t.
What is your Rails testing process? What kinds of tests do you write, and what tools do you use to write them?
Probably 90% of the tests I write these days are functional and unit tests, and the other 10% integration tests. As a subcontractor to many different teams, I’ve had the chance to experiment with a great many tools. The exposure has left me unconvinced that there’s a good ROI on either view testing or Cucumber-style BDD, though I recognize that reasonable people differ on this (and that different teams or different projects might have left me with a different impression).
When I have the luxury of picking my own tools these days, I find myself using Test::Unit, Shoulda, Mocha, and Object Daddy most often, with a side of parallel_test when the test suite grows. I’ve played with a couple of different CI servers as well, and at the moment I’m leaning towards Cerberus.
As far as process goes it’s a mix of TDD and more traditional top-down decomposition development with tests as I go; some of this just reflects my age in the industry, I’m sure. I do lots of little code spikes via git branching, and those usually don’t have tests involved; then I’ll come back to the branch I’m working on when I know where I’m going and write the tests and code together.
What’s the most interesting thing you’ve discovered about testing recently?
I’ve been spending a fair amount of time doing code reviews lately. It astonishes me how many teams – even good teams writing good code – have little to no test coverage. The fact that the code is good indicates that testing is not 100% essential – the fact that it has holes shows how it would help. And it’s also evident that the wider Rails community isn’t as test-infected as we like to think it is.
Is there a tool you wish you had for testing that you don’t think
currently exists?
I wouldn’t mind finding a good open source record-and-playback tool to use for browser-based integration and maybe even view testing. That used to be pretty useful, back in the day. For all I know one exists and I haven’t gone looking for it. I’d also like something that could do an automatic “lint” looking for cross-browser issues.
What advice would you give somebody looking to write more effective tests?
0) Buy Noel’s book. 1) Write tests. Like anything else, you improve if you do more of it. 2) Find a project you like and look at their tests to see how they did it. If you find patterns you can steal, go for it.
Weblinks:
Test Driven Development: A Tutorial (pdf)
Iptables Tutorials
Habe gerade nach einer Regel gesucht und bin dabei über zwei nette Iptables Tutorials gestolpert:
Iptables Tutorial 1.2.2
Tutorials – Iptables Tutorial (deutsch)
die ich mir hier schnell notiere, um sie später wieder zu finden. Auch der Artikel Wirksamer Schutz gegen DDoS (SYN-Flood) ist interessant zu diesem Thema.
Und Anzah der Verbindungen aller User anzeigen:
netstat -anp |grep 'tcp' | awk '{print $5}' | cut -d: -f1 | sort | uniq -c | sort -n und mit
iptables -p tcp --syn -m connlimit --connlimit-above 30 -j REJECT --reject-with tcp-rst mehr als 30 Verbindungen sperren fand ich auf Synflood verhindern.
Mit SYN-Cookies kann man auch auf TCP-Ebene mit sysctl net.ipv4.tcp_syncookies=1 Erfolg haben, schreibt dylan0.
Siehe dazu auch:
Ipsysctl tutorial 1.0.4
[Linux/Kernel] Paketfilter und SYN-Cookies
Linux Firewalls mit iptables & Co
iptables – Die Firewall des Kernels 2.4