Most projects are growing. New features get added, old ones deprecate. But as life goes on, ancient parts of the source code stay alive even if they're not being used anymore. My current cleanup challenge has 581k lines of code in 1500 files grown for about 15 years. Part one: Find defined, but unused subs.
Perl
Regular Expressions are powerful and typically fast. A recent script is using a set of about 1800 expressions (from a database) on roughly five million strings per day, typically 1 - 2 kB long. The RegEx matches take a lot of time and so I tried to speed them up. Working on the regular expression strings would be an option, but I also wanted to test if a methodic approach would help.
Manche Fehler passieren, obwohl man es eigentlich besser wissen müsste - nur einfach in dem Moment nicht daran denkt. So auch dieses Problem: 75 und 61 sind doch verschiedene Zahlen, wie können sie gleich sein? Sind sie nicht. Aber 075 und 61 sind gleich - und haben mich einige Zeit beschäftigt, bis ich das Rätsel gelöst hatte.
I started working myself though a long list of unfixed warnings today and encountered something I didn't see before: Reference found where even-sized list expected at project/Something.pm:573. The message seems to be clear, but do you find the problem at line 573?
Knapp vier Wochen nach dem German Perl Workshop 2014 haben die Organisatoren die Aufzeichnungen der Vorträge online gestellt, darunter auch mein Talk zum Thema Log everything... und dann?
Many functions, methods or subs (no matter how you call them) need some arguments. In Perl TIMTOWTDI, but some are faster than others. I'll compare eight ways to get arguments passed to a sub.
Software often needs to transform values from A to B. Such transformations (given they're static) might be done using a database table, if/elsif blocks or a mapping table. Such tables are easy to create, maintain and understand. A database is always the slowest solution for a limited number of items, because the overhead for the client, network and database server is very big compared to sourcecode processing. Sourcecode-based solutions are faster, but which one is the best.
Lars Dieckow (Daxim) and Curtis Poe (Ovid) both had talks at the German Perl Workshop 2014 in Hannover. Both topic have been very different, but it turned out that Ovid's talk on the last day also had some relation to a small discussion Daxim and I had after his talk. I didn't get it in time, but the connection between both came to my mind while planning this post.
"Log everything" ist seit einiger Zeit modern: Einfach alles protokollieren um im Bedarfsfall alle Debuggingdaten noch greifbar zu haben. Aber alles zu loggen ist nur die halbe Wahrheit, wenn man die Daten nicht angemessen aufbereitet. In meinem Talk auf dem German Perl Workshop 2014 habe ich unsere Lösung dieses Problems präsentiert.
TIMTOWDI: There is more than one way to do it ist das Perl-Credo. Some ways are better than others ergänzte Perl::Critic später und diesen Spruch möchte ich heute etwas abwandeln: Some ways are faster than others. Natürlich muss man sich die Frage stellen, wie wichtig Geschwindigkeit für eine Scriptsprache überhaupt ist. Sollten zeitkritische Aktionen nicht besser gleich in C oder einer ihrer Variationen geschrieben werden?
Nur noch 11 Tage, dann beginnt der 16. German Perl Workshop, dieses Jahr in Hannover. Seit Monaten sind die Jungs von Hannover.pm mit den Vorbereitungen beschäftigt. Nach der YAPC 2012 wird dies mein zweiter Perl-Kongress. Die DC13 letztes Jahr war ein Ausrutscher in die Welt abseits der Kamel-Zwiebel-Programmiersprache, aber der GPW2014 wird für mich eine nicht unwichtige Neuerung bringen.
Perl's "Regular Expression" Engine is one of the most flexible and powerful pattern matching and manipulation tools. "Easy" and "powerful" often behave like magnetic poles of the same kind: They can't be together. But the "s" and "m" suffix modifiers supported by the Perl RegEx engine aren't that complicated to understand but still very powerful.
Some errors are really hard to find: They appear only sometimes or only on live systems or within complex source that can't run manually using a debugger. Adding debug output might help, but might also be confusing as the DBI error code 4 "statement contains no result" does.
Im ersten Teil habe ich den Taint mode vorgestellt und gezeigt, wie gefährlich unbekannte Daten sein können. Jetzt geht es um die nicht minder wichtige Frage, wie man sich diese Daten trotzdem nutzbar machen kann. Das Ziel einer jeden (Web-)Anwendung sollte es sein, mit legitimen Eingaben problemlos und effizient umzugehen ohne dabei die Sicherheit gegenüber Betrugsversuchen leiden zu lassen.
(SQL) Injection ist immer wieder für Bugs gut, vor allem bei Webanwendungen, aber auch andere Stellen können ganz leicht sehr gefährlich werden. PHP hat das lange Zeit in eindrucksvoller Weise demonstriert - dazu reichte schon ein sehr simples index.php:
