tag:blogger.com,1999:blog-36345871Sat, 22 Oct 2016 20:15:37 +0000ironmanPerl Alchemy - notes of a programmerhttp://perlalchemy.blogspot.com/noreply@blogger.com (zby)Blogger158125tag:blogger.com,1999:blog-36345871.post-3248062808984217637Fri, 29 Nov 2013 10:15:00 +00002013-11-29T02:20:53.065-08:00Debugging bayesian filters<div dir="ltr" style="text-align: left;" trbidi="on">It is a common problem when a trained filter miscategorizes something and you'd like to know why - what is really the feature that puts the most weight into the wrong category? Or sometimes you'd like to know what are the features that puts another object into the right category - maybe we should add them somehow to the object? In <a href="http://search.cpan.org/~zby/AI-NaiveBayes-0.01/lib/AI/NaiveBayes/Classification.pm">AI::NaiveBayes::Classification</a> there is a method called <code>find_predictors</code> that finds the most features that weight most for and against the category that a given object is eventually classified under. The <a href="https://github.com/operasoftware/AI-NaiveBayes/blob/master/lib/AI/NaiveBayes/Classification.pm#L23">simple algorithm</a> assumes that there are only two categories - but it should be possible to extend it for more categories. The returned numbers are hard to interpret - but what is important is how big they are in comparison with other numbers in the result. <p>We use the classifier for spam detection - whenever we get misclassified posts I check what words (or other features) push them into the wrong category and I decide what to do - should be improve the training examples, add more post features or maybe we can just ignore the case. When improving the filters, by adding or removing examples I can check how that changes the classification and also how exactly it changes the influence of each important feature on the result. <br /></div>http://perlalchemy.blogspot.com/2013/11/debugging-bayesian-filters.htmlnoreply@blogger.com (zby)0tag:blogger.com,1999:blog-36345871.post-3773097149956870003Fri, 11 Jan 2013 10:14:00 +00002013-01-11T02:14:37.099-08:00Immutable objects and Dependency Injection<div dir="ltr" style="text-align: left;" trbidi="on">At some point we had:<br /><script src="https://gist.github.com/4509300.js"></script>in our code. <p><code>Text::FeatureCount</code> was at that time an accumulator that was counting the document features and saving them in internal structures. Multiple subroutines were using these structures - so it made sense to make them the object attributes. But it also meant that changing <code>Text::FeatureCount</code> into something else was a big deal. We could make the class name variable: <code>$feature_counter_class->new->analyze(...</code> and add an attribute to store it to the main object. But I decided to make <code>Text::FeatureCounter</code> an immutable object instead and <em>inject</em> a ready made <code>Text::FeatureCounte</code> into the object doing the work above. Now it can be used in the loop without re-constructing it to clean the internal structures. When coding with immutable objects you have to pass around the input data from one method to another explicitly instead of keeping it readily available in the object attributes: <script src="https://gist.github.com/4509425.js"></script> This makes it is slightly <em>un-object-oriented</em>, but the benefit is that you don't need to re-construct the object and so you can use Dependency Injection on it and make the code more flexible. It is also easier to reason about the algorithm when some parts are immutable. Often this is a good trade-off. <p/>PS. After much other refactoring <code>Text::FeatureCount</code> mutated into <a href="https://github.com/operasoftware/Text-WordCounter"><code>Text::WordCounter</code></a> (and <code>AI::Classifier::Text::Analyzer</code>) - soon to be released to CPAN. <br /></div>http://perlalchemy.blogspot.com/2013/01/immutable-objects-and-dependency.htmlnoreply@blogger.com (zby)0tag:blogger.com,1999:blog-36345871.post-8414493085142663429Wed, 31 Oct 2012 11:01:00 +00002012-10-31T04:01:03.239-07:00Dependency Injection and open-sourcing generic parts of apps<div dir="ltr" style="text-align: left;" trbidi="on"><a href="http://perlalchemy.blogspot.com/2011/08/cpan-decoupling-and-dependency.html">using DI in CPAN libs makes them more universal</a> - but DI even more important is when you want to open-source some generic part of your application. Your boss agrees and then you encounter code like this: <script src="https://gist.github.com/3986332.js?file=gistfile1.pl"></script> <br /></div>http://perlalchemy.blogspot.com/2012/10/dependency-injection-and-open-sourcing.htmlnoreply@blogger.com (zby)0tag:blogger.com,1999:blog-36345871.post-652296293552607579Sat, 06 Oct 2012 07:23:00 +00002012-10-06T00:23:30.066-07:00A simple quine<div dir="ltr" style="text-align: left;" trbidi="on">I wrote a <a href="http://en.wikipedia.org/wiki/Quine_(computing)">quine</a>:<br /><script src="https://gist.github.com/3844302.js?file=quine.pl"></script><br /></div>http://perlalchemy.blogspot.com/2012/10/a-simple-quine.htmlnoreply@blogger.com (zby)0tag:blogger.com,1999:blog-36345871.post-623985270945718276Thu, 30 Aug 2012 07:59:00 +00002012-08-30T00:59:19.335-07:00Interactive presentations<div dir="ltr" style="text-align: left;" trbidi="on">At my latest <a href="http://act.yapc.eu/ye2012/talk/4175">YAPC talk</a> I used questions to the audience to make sure that everything is understood. That does not mean that I asked 'do you understand it' - but rather I asked 'how would you estimate this or that' - and then I extracted from the answers the generic strategies that I had prepared to talk about. This worked spectacularly well and I think I'll add it to all my presentations. <br /></div>http://perlalchemy.blogspot.com/2012/08/interactive-presentations.htmlnoreply@blogger.com (zby)0tag:blogger.com,1999:blog-36345871.post-6002594795463615218Thu, 07 Jun 2012 20:38:00 +00002012-06-07T13:38:36.249-07:00Why web frameworks tend to grow to become such unwieldy beasts?<div dir="ltr" style="text-align: left;" trbidi="on">Most of the web frameworks I know tend to do at least two things - the web stuff plus creation and initialization of all other components. This means that the framework is coupled with all of these components and this is the root of all evil in web frameworks. Of course you need a place to do that object creation and wiring work - but it is not really related to web stuff - it should have it's own place in the program, ideally in a Dependency Injection compartment, not necessarily a container based on the available libraries - but it can also be coded by hand (I might change my minde some day but for now <a href="http://perlalchemy.blogspot.com/2012/03/why-breadboard-is-mostly-redundant.html">I don't see any reasons to use DI container libraries in a dynamic language like Perl</a>). All the <a href="http://misko.hevery.com/2008/07/08/how-to-think-about-the-new-operator">arguments</a> about <a href="http://perlalchemy.blogspot.com/2011/08/cpan-decoupling-and-dependency.html">using</a> Dependency Injection apply also here, but even for someone rejecting DI it should be pretty obvious that reading config files and initializing objects is not much related to web stuff and if you buy the single responsibility principle you should split them into separate libraries. <p>I don't know <a href="http://news.ycombinator.com/item?id=4076834">Django</a> or Rails too deeply - but I've <a href="http://blog.urth.org/2009/08/how-i-use-catalyst.html">observed this with Catalyst</a>. Now, Catalyst is supposed to be decoupled from the Views or Models and other Plugins, there are many different ones in each category and you can replace them freely in your programs. But Catalyst code-base is still pretty big and then you have all these Catalyst::Models, Catalyst::Views and Catalyst::Plugins that don't really do any meaningful work - they only map one interface into another one. It could be much simpler if Catalyst only cared about the web related processing. <br /></div>http://perlalchemy.blogspot.com/2012/06/why-web-frameworks-tend-to-grow-to.htmlnoreply@blogger.com (zby)4tag:blogger.com,1999:blog-36345871.post-8090816379739347956Sat, 12 May 2012 18:10:00 +00002012-05-12T11:10:18.866-07:00Non compatible changes in WebNano<div dir="ltr" style="text-align: left;" trbidi="on">In <a href="https://github.com/zby/WebNano/commit/85a9c83ad21e6ceaa8dbbc345a626f815e602ae5">my latest commit in WebNano</a> I refactored a lot of code and changed the API in a non-compatible way. I am going to make a new release with those changes soon. I feel that doing an additional release only to warn about this fact before that sounds kind of silly - isn't announcing it here enough? <br /></div>http://perlalchemy.blogspot.com/2012/05/non-compatible-changes-in-webnano.htmlnoreply@blogger.com (zby)1tag:blogger.com,1999:blog-36345871.post-5858266703461194549Mon, 07 May 2012 13:01:00 +00002012-05-07T06:06:33.141-07:00On the importance of intuitive names.<div dir="ltr" style="text-align: left;" trbidi="on"><blockquote>PARTICIPANT:<br/><br/><em>[Reading names of classes]</em><br/><br/>Binary reader, Buffered stream, Reads and writes...<br/><br/><em>[Pauses, Scrolls through list of classes].</em><br/><br/>So let me just...stream writer. Implements a text writer writing characters to a stream in a particular encoding. Umm...stores an underlying string. Text...hmmm. Text reader, text writer. Represents a writer that can write a sequential series of characters. This class is abstract.<br/><br/><em>[Pause]</em><br/><br/>Ummm...<br/><br/><em>[scrolls up and down through list of classes]</em><br/><br/>So it, you know, it sounds to me like it's, you know, it's more low-level kind of stuff. Whereas I just want to create a text file. Umm.<br/><br/><em>[Points at the description of one of the classes]</em><br/><br/>Characters to a stream in a particular encoding. I'm not sure what...obviously a text writer for writing characters to a stream.<br/><br/><em>[Clicks on the link to view more details about the TextWriter class. Then looks at list of classes that derive from TextWriter]</em><br/><br/>System dot IO dot StringWriter. This seems too low-level to me to be a text writer thing but maybe I am wrong. Umm...<br/><br/><em>[scrolls through description of the TextWriter class]</em><br/><br/>Text writer is designed for character output, whereas the stream class is designed for byte input and output.<br/><br/><em>[Sigh. Clicks on link to view TextWriter members]</em><br/><br/>Probably going where no man should have gone before here.<br/><br/></blockquote> This guy did not make it. <p>Neither did any of the other 7 professional programmers that were participants in that experiment! Their task was "to write a program that would write to and read from text files on disk". They had 2 hours for that and could browse all of the relevant documentation. They were testing the API of the then new programming framework called .NET - the programmers did not know it yet - but they had programmed in VisualBasic. This is an example code fragment using the file writing API that they were expected to write: <script src="https://gist.github.com/2623785.js?file=gistfile1.vb"></script> After that experiment they added a new 'File' API: <script src="https://gist.github.com/2623798.js?file=gistfile1.vb"></script> and ran the experiment again. This time all participants were able to complete each task in 20 minutes and without browsing the documentation. This is the story from the "Chapter 29 How Usable Are Your APIs?" in <a href="http://shop.oreilly.com/product/9780596808303.do">Making Software</a>. <p> Fascinating puzzle - isn't it? The article proposes following solution to it: there are three types of programmers - opportunistic, pragmatic and systematic. The opportunists tend to use the high-level abstractions and try and experiment with what would work and they intuitively get the File API as opposed to the <code>StreamWriter</code> API. And it just happened that all 8 participants of that study were opportunist programmers?! <blockquote>The developers who participated in the file I/O studies were very much in the opportunistic camp. The way they used the <code>FileObject</code> class in the second study was almost a perfect example of opportunistic programming. The contrast with the more abstract classes they had to use in the first study was stark. Indeed, one of the main findings from the file I/O studies was that without such high-level concrete components, opportunistic developers are unlikely to be successful. </blockquote>Sounds like a weak argument: <ol><li>Copy pasting examples and playing with the code is the most efficient way to learn a new API - so I suspect that what they call 'opportunistic programming' is actually learned behaviour that would be characteristic of any experienced programmer. <li>Expecting a file related API sounds quite natural and not really related to being opportunistic or systematic, the task at hand was exactly file related IO and in most programming languages there is such an API, it also makes sense that there is one because file operations are very common. <li>I don't see anything higher level or more concrete in the <code>FileObject</code> related example code - it looks on the same level of abstraction as the <code>StreamWriter</code> code. The authors claim that it is the fact that you have both <code>StreamWriter</code> and <code>StreamReader</code> that makes it lower level then <code>FileObject</code> which is only one - but I don't see how that follows. </ol> Phil Karlton wrote: <blockquote><a href="http://martinfowler.com/bliki/TwoHardThings.html">There are only two hard things in Computer Science: cache invalidation and naming things. </a></blockquote>Naming things also comes out as quite important. </div>http://perlalchemy.blogspot.com/2012/05/on-importance-of-intuitive-names.htmlnoreply@blogger.com (zby)0tag:blogger.com,1999:blog-36345871.post-6512000024386452633Wed, 02 May 2012 14:45:00 +00002012-05-02T07:46:22.104-07:00Tricky problems of the Perl language - a completely arbitrary list<ol><li><a href="http://blog.urth.org/2010/10/whats-wrong-with-perl-5s-overloading.html">Overloading and parameter types validation.</a><li><a href="http://www.modernperlbooks.com/mt/2012/03/inadvertent-inconsistencies-each-versus-autoderef.html">Clash between overloading hashification and arrayification and the <code>each, keys</code> and <code>values</code> with the new dereferencing semantics.</a><li><a href="http://perlalchemy.blogspot.com/2011/08/isutf8-is-useless-can-we-have.html">There is no way to know if you received characters or binary data</a>, lots of libraries and even core functions <a href="http://perlalchemy.blogspot.com/2011/10/open-expects-filename-as-binary-data.html">work differently in these cases</a> - but often it is not documented. <li>In Perl observing a variable changes it - for example - reading a variable containing a string in a number context will fill in its number slot (as far as I understand it - see <a href="http://perldoc.perl.org/perlguts.html">perlguts</a> for the details). Normally it does not matter - but it makes threading less efficient (because shared variables need to go through additional loops to work). </ol> Two bonus points - using too much of the <code>$</code> character makes <ol><li><a href="http://perlalchemy.blogspot.com/2011/01/is-responsible-for-ugliness-of-perl.html">Perl code ugly</a><li><a href="http://perlalchemy.blogspot.com/2011/11/primes-for-money.html">Perl programmers not team players</a></ol>And one more fixed recently - <a href="http://perldoc.perl.org/perl5140delta.html#Exception-Handling">the one making checking <code>$@</code> after eval unreliable</a>.http://perlalchemy.blogspot.com/2012/05/tricky-problems-of-perl-language.htmlnoreply@blogger.com (zby)0tag:blogger.com,1999:blog-36345871.post-7652871315240926409Fri, 27 Apr 2012 11:19:00 +00002012-04-27T07:08:37.431-07:00If all of your state is on the stack then you are doing functional programming<div dir="ltr" style="text-align: left;" trbidi="on">Consider this: <script src="https://gist.github.com/2508313.js?file=gistfile1.pl"></script>This is imperative code, it uses variables with state, but from the outside it is a pure mathematical function. This is because all of its variables are created anew when the function is being executed and destroyed after that. It does not matter that the variables contain simple values: <script src="https://gist.github.com/2508353.js?file=gistfile1.pl"></script>This can also be purely functional provided that Markdent::Simple::Document does not use globals or system calls. <p>Imagine that this was enforced by the compiler/interpreter - maybe with a new keyword <code>function</code>, or something. I have the feeling that this would be very similar to how <code>use strict</code> works - giving the end user <a href="http://en.wikipedia.org/wiki/Referential_transparency_(computer_science)">some kind of safety</a>. <br /></div>http://perlalchemy.blogspot.com/2012/04/if-all-of-your-state-is-on-stack-then.htmlnoreply@blogger.com (zby)3tag:blogger.com,1999:blog-36345871.post-7131366828189716026Tue, 17 Apr 2012 10:19:00 +00002012-04-20T01:04:39.698-07:00A Data::Dumper bug - or Latin1 strikes againI did not believe my boss that he found a bug in Data::Dumper - but run this: <br /><script src="https://gist.github.com/2404891.js?file=gistfile1.pl"></script><br />To get a character that has internal representation in Latin1 I could also use <tt>HTML::Entities::decode( '&amp;oacute;' )</tt> there with the same result. The output I get on 5.14.2 and 5.10.1 is: <br /><script src="https://gist.github.com/2404904.js?file=gistfile1.txt"></script><br />When I check the dumped string - it has the right character encoded in Latin1 - and apparently eval expects UTF8 when <code>use utf8</code> is set. Without <code>use utf8</code> eval works OK on it. If the internal representation of the initial character is UTF8 (like when the first line is <code>my $initial = 'ó';</code>) - then the dumped string contains UTF8 (which is again might be interpreted incorrectly if the code does not have <code>use utf8</code> preamble). <p>Considering that Data::Dumper is a core module and one that is one of the most commonly used and that <a href="http://search.cpan.org/perldoc?Data::Dumper">its docs say:</a><blockquote>The return value can be evaled to get back an identical copy of the original reference structure. </blockquote>this looks like a serious bug. <p>Is that a known problem? Should I post it to the Perl RT? <p><b>Update:</b> Removed the initial eval - <code>"\x{f3}"</code> is enough to get the Latin1 encoded character. Some editing. <br /><b>Update:</b> I tested it also on 5.15.9 and it fails in the same way. <br /><b>Update:</b> <a href="https://rt.perl.org/rt3/Ticket/Display.html?id=112532">I've reported it to the Perl RT</a> - I am not sure about the severity chosen and the subject - this was my first Perl bug report. <br /><b>Update:</b> In reply to the ticket linked above Father Chrysostomos explains: "The real bug here is that ‘eval’ is respecting the ‘use utf8’ from outside it." and later adds that 'use v5.16' will fix the problem in 5.16.http://perlalchemy.blogspot.com/2012/04/datadumpereval-utf8-bug-or-latin1.htmlnoreply@blogger.com (zby)3tag:blogger.com,1999:blog-36345871.post-1737711602926738269Sat, 14 Apr 2012 14:30:00 +00002012-04-14T14:05:46.174-07:00Breaking problems down and defaults<div dir="ltr" style="text-align: left;" trbidi="on"><div dir="ltr" style="text-align: left;" trbidi="on">In a classic essay Dave Rolsky wrote: <a href="http://blog.urth.org/2009/11/want-good-tools-break-your-problems-down.html">Want Good Tools? Break Your Problems Down</a>. I wish more people have read this and applied the advice - CPAN libraries would be more useful then. But stating the goal is probably not enough - we need also to talk about how it can be reached and about problems encountered on the way there. For example let's take the <a href="http://search.cpan.org/perldoc?Markdent">module that was the result of the process described in the essay linked above</a>: <br /><div class="separator" style="clear: both; text-align: center;"><a href="http://1.bp.blogspot.com/-ya5ko6d-lag/T4lbwWqQ1OI/AAAAAAAAAEo/95fMG4noFhA/s1600/markdent.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" src="http://1.bp.blogspot.com/-ya5ko6d-lag/T4lbwWqQ1OI/AAAAAAAAAEo/95fMG4noFhA/s1600/markdent.png" /></a></div><br />The problem is that the criticized approach, a unified library that just converts Markdown to HTML, would result in a simpler API - for example something like this: <br /><div class="separator" style="clear: both; text-align: center;"><a href="http://3.bp.blogspot.com/-LAwMPCfamCs/T4liQvb7iGI/AAAAAAAAAE4/EL4OLX4rBZg/s1600/markdown.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img alt="" border="0" src="http://3.bp.blogspot.com/-LAwMPCfamCs/T4liQvb7iGI/AAAAAAAAAE4/EL4OLX4rBZg/s1600/markdown.png" title="" /></a></div><br />Maybe the difference does not look very significant - but after a while it can get annoying. For the 99% of cases you don't need to extra flexibility that comes with the replaceable parser - so why should you pay for it? &nbsp;If I had to use Markdent frequently I would write a wrapper around it with an API like above.<br /><br />By the way,&nbsp;<a href="http://search.cpan.org/perldoc?Text::Markdown">Text::Markdown</a>&nbsp;already has this wrapper and it does present a double, functional/object oriented API - where the presented above simple, functional one does the most common thing, while the object oriented one gives you more control over the choices made. &nbsp;Only that it still couples parsing and generation.<br /><br />Another way of simplifying the API is providing defaults to function arguments. For example&nbsp;<a href="http://perlalchemy.blogspot.com/2011/08/cpan-decoupling-and-dependency.html">to the object constructor</a>. &nbsp;Dependency Injection is all about breaking the problem down and making flexible tools - &nbsp;but it might become unbearable if we not soften it up a bit with defaults.<br /><br />Programming is always about doing trade-offs - here we add some internal complexity (by adding the wrappers or providing the defaults) and in exchange get a simplified API that covers the most common cases while still maintaining the full power under the hood. &nbsp;I think this is a good trade off in most cases, and especially in the case of libraries published to CPAN that need to be as universal as possible.</div></div>http://perlalchemy.blogspot.com/2012/04/breaking-problems-down-and-defaults.htmlnoreply@blogger.com (zby)2tag:blogger.com,1999:blog-36345871.post-5341153798996087085Thu, 05 Apr 2012 05:33:00 +00002012-04-05T05:24:26.406-07:00What if "character != its utf8 encoding" is overengineering?"You shell not assume anything about the internal representation of characters in Perl" - is a <a href="http://juerd.nl/files/slides/2007yapceu/unicodetutorial.html">mantra</a> that has been repeated over and over by the Perl pundits for something like a decade. But there are still <a href="http://perlalchemy.blogspot.com/2011/08/isutf8-is-useless-can-we-have.html?showComment=1314694282622#c6709443747151148303">people who refuse to take that advice</a> and want to peek into the internal representation of characters. What if our sophisticated approach about isolating the 'idea of a character' and its representation is a case of overengineering? People often overreact for past traumas - programming is not an exception - and the conversion from many national 'charsets' to unicode was a big event. Maybe expecting another conversion soon is such an overreaction? <p>Getting rid of the Latin1 internal encoding does not look like a big price for improving simplicity and getting rid of all these subtle mistakes. I think it is important that the language is understood by its users and if it is not, then maybe, instead of blaming the programmers, we could make it easier to understand? Sure it is nice to have the possibility to change the internal encoding from UTF8 to UTF16 or maybe something completely different in the future - but I have the feeling that this might be case of architecture astronautics.http://perlalchemy.blogspot.com/2012/04/what-if-character-its-utf8-encoding-is.htmlnoreply@blogger.com (zby)0tag:blogger.com,1999:blog-36345871.post-3762080205178429869Sat, 31 Mar 2012 08:06:00 +00002012-03-31T01:06:40.068-07:00Plack::Middleware::Auth::Form - some updates and a possible name changeI'll make a new release of Plack::Middleware::Auth::Form soon. There are quite a few <a href="https://github.com/zby/Plack-Middleware-Auth-Form/blob/master/Changes#L27">fixes</a> in the Plack::Middleware::Auth::Form repository gathered since the last release. It is all from external contributors - thanks a lot! <p>The bug reported in <a href="https://rt.cpan.org/Ticket/Display.html?id=75896&results=16310ff93543b19d4aac76453cf23d85">#75896: Cookie Expiry Date not set for "remember" session</a> is quite interesting. Apparently Plack::Middleware::Session sends the session cookie on each request and if you don't set Expiry Date each time it will happily unset it. <p>I am thinking about changing the name to WebPrototypes::LoginForm. Some people did not like the name Plack::Middleware::Auth::Form from the start, because it is a bit more high-level then the other Auth middlewares, and now I have <a href="https://github.com/zby/WebPrototypes-ResetPass">two</a> more <a href="https://github.com/zby/WebPrototypes-Registration">elements</a> for quick web application prototyping under the WebPrototypes namespace.http://perlalchemy.blogspot.com/2012/03/plackmiddlewareauthform-some-updates.htmlnoreply@blogger.com (zby)0tag:blogger.com,1999:blog-36345871.post-1723865746024716212Sun, 25 Mar 2012 13:03:00 +00002012-03-26T00:00:15.172-07:00Blog writing and assuming stupidityWriting a blog is not easy. People did not change much since the 'bread and circuses' times. You need to spicy your writing up with <a href="http://perlalchemy.blogspot.com/2010/02/frameworks-are-framing-libraries-are.html">strong statements</a> or you'll not get any audience. On the other hand <a href="http://perlhacks.com/2012/03/you-must-hate-version-control-systems/">ridiculing someone</a> while having <a href="http://perlhacks.com/2012/03/you-must-hate-version-control-systems/#comment-3928">a very superficial knowledge of the matter</a> makes you a bully. <p>What happened there? Again, it is hard to tell anything interesting without some speculation - and possibly I'll have to apologize to Dave for this - but I think Dave has read "You must hate version control systems, we won't be using any" and <em>assumed</em> that this is is from a company that superficially rejected version control because they did not want to learn or, in other words, from someone that <em>assumed</em> that version control is useless. Talk about beams and eyes. That's not to say that I vouch for the 'pipelines' system or for replacing version control with it. I still don't know much about these pipelines - but new ideas don't have to <a href="http://www.interaction-design.org/encyclopedia/disruptive_innovation.html">work in every possible aspect to be worthwhile</a> and you'll not have a break-through idea if you always stick to the accepted wisdom. <p>It is easy to assume stupidity - on average people are mediocre - but the internet is a big search space - expect to be surprised from time to time :)http://perlalchemy.blogspot.com/2012/03/blog-writing-and-assuming-supidity.htmlnoreply@blogger.com (zby)3tag:blogger.com,1999:blog-36345871.post-4135392514189646103Mon, 19 Mar 2012 12:34:00 +00002012-03-19T08:42:03.957-07:00Verbs and NounsThere is a popular, if a bit long and blurry, rant by Steve Yegge: <a href="http://steve-yegge.blogspot.com/2006/03/execution-in-kingdom-of-nouns.html">Execution in the Kingdom of Nouns</a> - it is about how we overuse nouns and under-use verbs when programming in Java. Of course it is not different in other object oriented imperative languages. Programs do something, subroutines do something - verbs should be at least as prominent as nouns in programming - but when we need to write an application we build it out of objects. Even if it is a web application - something that translates the HTTP request into the HTTP response - we code it as an object with fields and all that stuff. Even if we code against an <a href="http://search.cpan.org/dist/PSGI/">API that defines the web application as a subroutine reference</a>, we still write it as an object and then <a href="http://perlalchemy.blogspot.com/2010/05/psgi-and-object-oriented-programming.html">make a closure over it</a> to pass to the backend. <p>Do we overuse nouns? Or maybe it is that actions are opaque and unstructured - and when we need to get to the the details, the parts that compose them - then it is more natural to treat them as things? Wouldn't it be easier to incorporate <a href="http://search.cpan.org/dist/PSGI/PSGI.pod#Delayed_Response_and_Streaming_Body">streaming in PSGI</a> if the application there was an object with methods and attributes?http://perlalchemy.blogspot.com/2012/03/verbs-and-nouns.htmlnoreply@blogger.com (zby)0tag:blogger.com,1999:blog-36345871.post-1988488097464439739Sun, 11 Mar 2012 19:38:00 +00002012-03-11T12:38:14.972-07:00WebNano - code experimentsWebNano is only a few hundreds lines - but you can arrange it in many many ways - and then you need to test it with all kinds of URL schemas and controller architecture. I do a lot of exploratory coding - testing all the possible arrangements. I feel that I keep forgetting about the things that suggested me to choose one design over others. Maybe I'll keep some notes here. In the past two weeks I tried a few things: <ol><li>Keeping the parsed path as an attribute in the controller. <li>Additionally to the above I <a href="https://github.com/zby/WebNano/tree/path_as_attr">tried adding three more controller methods</a>: 'action_name', 'action_args' and 'action_postfix'. <li>I wrote two additional test controllers for the simple url schema, both redirecting handling to <a href="https://github.com/zby/WebNano/blob/master/examples/DvdDatabase/lib/DvdDatabase/Controller/Dvd/Record.pm">DvdDatabase::Controller::Dvd::Record</a> for the case where we have a record to handle: <a href="https://github.com/zby/WebNano/blob/master/examples/DvdDatabase/lib/DvdDatabase/Controller/DvdSimpleUrl_TwoClasses.pm">overriding local_dispatch</a>, <a href="https://github.com/zby/WebNano/blob/master/examples/DvdDatabase/lib/DvdDatabase/Controller/DvdSimpleUrl_HandlerOv.pm">overriding handle</a></ol>The conclusions: <ol><li> having the path as attribute is handy for code retrieving the record <li> the additional controller methods help with writing custom dispatchers <li> splitting the processing to two controllers - one for the case where you have one object to work on (like viewing, editing, deleting), second for the case where we don't (like listing, creating) is very clean - you can have the object as controller attribute <li> the the additional dispatcher methods are less useful for that more clean architecture <li> the biggest problem was always preventing the methods that require the object to be called when we don't have the record id on the path (like '/view' when we assume that it should be '/1/view') - and the best method to do that is having the two controller classes <li> overriding 'handle' is actually simpler - because it is a very simple method </ol>http://perlalchemy.blogspot.com/2012/03/webnano-code-experiments.htmlnoreply@blogger.com (zby)0tag:blogger.com,1999:blog-36345871.post-488893169771462611Tue, 06 Mar 2012 15:18:00 +00002012-03-07T01:34:02.472-08:00Why Bread::Board looks mostly redundantThis is based on two assumptions - that you don't use BB as a kind of Service Locator (but I agree with for example <a href="http://www.loosecouplings.com/2011/01/dependency-injection-using-di-container.html">Dependency Injection != using a DI container</a> that this is an anti-pattern) and what 'mostly follows' that the product of your BB container is just one object - the application class. I believe these are good guidelines for software architecture. With those two assumptions all that BB gives you is that you can name your partial results and then use them in later computations, but Perl has a good support for this - it is called <em>variables</em>. <p>For example let's take the original example from Bread::Board synopsis: <script src="https://gist.github.com/1986741.js?file=gistfile1.pl"></script> Now - let's do the same with just <b>variables</b>: <script src="https://gist.github.com/1986752.js?file=gistfile1.pl"></script> You can also feel fancy and do it with <a href="http://www.modernperlbooks.com/mt/2012/02/the-memoization-of-lazy-attributes.html">Moose lazy attributes</a>: <script src="https://gist.github.com/1992168.js?file=gistfile1.pl"></script> This is not longer than the BB example and it uses <em>generic</em> tools.http://perlalchemy.blogspot.com/2012/03/why-breadboard-is-mostly-redundant.htmlnoreply@blogger.com (zby)9tag:blogger.com,1999:blog-36345871.post-7922925364281849807Fri, 02 Mar 2012 15:41:00 +00002012-03-02T07:44:32.627-08:00Mason 2<a href="http://search.cpan.org/~jswartz/Mason-2.16/lib/Mason/Manual/Tutorial.pod">Mason 2</a> looks very interesting. First of all it has the a file a page modus operandi that works so well for PHP, then it has all the template inheritance and Moose template candies that look very powerful, finally the page code works in the request scope - i.e. it can access the page parameters and stuff from attributes <a href="http://misko.hevery.com/2009/04/15/managing-object-lifetimes/"> which is so much more convenient</a> then passing these values around as method parameters as you do in Catalyst. The only part lacking from my cursory look at the documentation is anything that works in the application scope. Most probably it is just that I did not found anything in the most exposed documents - but this omission still looks ominous.http://perlalchemy.blogspot.com/2012/03/mason-2.htmlnoreply@blogger.com (zby)0tag:blogger.com,1999:blog-36345871.post-2156579344289749283Sun, 15 Jan 2012 07:48:00 +00002012-01-15T01:09:25.512-08:00SchlepSchlep is tedious, unpleasant task. &nbsp;<a href="http://paulgraham.com/schlep.html%22">According to Paul Graham schlep is also what really defines a company</a> - it is doing the tasks that are unpleasant and tedious for someone that they would pay you for.<br /><br />Narrowing this down to my own Perl web development work - the schlep for me was always getting the basic web app running with user registration, login pages, password reset mechanisms, etc. - in every new project that was the most repeatable, boring work. &nbsp;I think everyone has the feeling that this does not need to be like that. &nbsp;I've started thinking about what could be a solution to this and here are my first experiments about fixing it: <a href="https://github.com/zby/Plack-Middleware-Auth-Form">Plack-Middleware-Auth-Form</a>,&nbsp;<a href="https://github.com/zby/WebPrototypes-ResetPass">WebPrototypes::ResetPass</a>, <a href="https://github.com/zby/WebPrototypes-Registration">WebPrototypes::Registration</a> (I might rename the first one to WebPrototypes as well). &nbsp;The point is to solve it across the multiple web frameworks, templating languages and storage layers - so that it can survive moving from project to project.<br /><br />What is your schlep?http://perlalchemy.blogspot.com/2012/01/schlep.htmlnoreply@blogger.com (zby)0tag:blogger.com,1999:blog-36345871.post-8393565161125011126Sat, 10 Dec 2011 21:20:00 +00002011-12-10T13:35:15.229-08:00A kind of call by nameI often write code like this:<br /><blockquote class="tr_bq">$self-&gt;create_user( username =&gt; $username, email =&gt; $email, pass_token =&gt; $pass_token );</blockquote>I wish I could get rid of the naming redundancy in this call:<br /><blockquote class="tr_bq">$self-&gt;create_user( $username, $email, $pass_token );</blockquote>(without changing 'create_user' of course).<br /><br />Probably some new syntax would be needed.http://perlalchemy.blogspot.com/2011/12/kind-of-call-by-name.htmlnoreply@blogger.com (zby)4tag:blogger.com,1999:blog-36345871.post-703066386380546246Sat, 19 Nov 2011 07:42:00 +00002011-11-21T01:46:53.115-08:00'use strict' and cargo cult programmingI've just read&nbsp;<a href="http://perl.plover.com/yak/12views/samples/notes.html#sl-31"> mjd's confession "Why I Hate strict"</a>,&nbsp;it is from 2003 so he might have changed his views now, but there is nothing that would indicate that on this web page. &nbsp;Anyway, his main argument that the usual advice to <span class="Apple-style-span" style="font-family: 'Courier New',Courier,monospace; font-size: x-small;">use strict</span>&nbsp;is automatic and mindless &nbsp;and that it often does not really prevent the problems that people think it does. &nbsp;In other words it is a&nbsp;<a href="http://en.wikipedia.org/wiki/Cargo_cult">cargo cult</a>&nbsp;programming to which he contrast programming with thinking and deep analysis of everything you do.<br /><br />I used to program without <span class="Apple-style-span" style="font-family: 'Courier New',Courier,monospace; font-size: x-small;">use strict; use warnings</span>&nbsp;but after exposure to the usual propaganda I switched and I found that the cost of mindlessly adding it is&nbsp;negligible, the cases where I need <span class="Apple-style-span" style="font-family: 'Courier New',Courier,monospace; font-size: x-small;">no strict</span>&nbsp;are very rare, and there are many benefits of doing it, especially when working with old code. &nbsp;This cult is rather effective in luring the cargo planes to land in my&nbsp;atoll. &nbsp;On the other hand I am all for deep analysis and checking your assumptions from time to time. &nbsp;There are many valid points in Marc Lehman&nbsp;<a href="http://search.cpan.org/perldoc?common::sense">common::sense</a>&nbsp;and I would like to see them discussed. &nbsp;While we are on the road to have <span class="Apple-style-span" style="font-family: 'Courier New',Courier,monospace; font-size: x-small;">use strict</span> by default we might also try to make it better.http://perlalchemy.blogspot.com/2011/11/use-strict-and-cargo-cult-programming.htmlnoreply@blogger.com (zby)5tag:blogger.com,1999:blog-36345871.post-3094980317057709332Sat, 12 Nov 2011 12:22:00 +00002011-11-12T07:29:29.180-08:00$ primes for moneyThe thesis above sounds uncontroversial. &nbsp;It is also rather uncontroversial that '$' is relatively frequently used when programming in Perl. &nbsp;Now - what can be&nbsp;<a href="http://www.google.com/search?gcx=c&amp;sourceid=chrome&amp;ie=UTF-8&amp;q=priming+for+money">the consequences of that</a>?<br /><blockquote class="tr_bq">Money has been said to change people's motivation (mainly for the better) and their behavior toward others (mainly for the worse). The results of nine experiments suggest that money brings about a self-sufficient orientation in which people prefer to be free of dependency and dependents. Reminders of money, relative to nonmoney reminders, led to reduced requests for help and reduced helpfulness toward others. Relative to participants primed with neutral concepts, participants primed with money preferred to play alone, work alone, and put more physical distance between themselves and a new acquaintance.</blockquote>from <a href="http://www.sciencemag.org/content/314/5802/1154.abstract">one of the first links in the query above</a>. &nbsp;Pretty sad - can that apply to the Perl community? Another link from that list,&nbsp;<a href="http://www.youtube.com/watch?feature=player_embedded&amp;v=mW2SByfHpYg">an entertaining BBC video report</a>&nbsp;suggests also some other effects: hunger and pain insensitivity.http://perlalchemy.blogspot.com/2011/11/primes-for-money.htmlnoreply@blogger.com (zby)1tag:blogger.com,1999:blog-36345871.post-4573187674804750715Mon, 07 Nov 2011 18:21:00 +00002011-11-08T03:07:06.716-08:00Thesis: simple - antythesis: easy - synthesis: ...Rich Hickey's <a href="http://www.infoq.com/presentations/Simple-Made-Easy">Simple Made Easy</a> is a great talk, a must see, with lot's of insight, but together with that it also misrepresents what Agile is about.&nbsp; Hickey's main point is that we should try to write simple software, because this is the only way to have reliable software, and he is right of course. &nbsp; He notes that when you encounter a new bug and try to fix it - all the existing tests pass - so they will not help you in finding the cause of it.&nbsp; You need to do the bug analysis on your own&nbsp; and the complexity of your code is your enemy there.&nbsp; He is also right when he talks about how <i>easy</i>&nbsp;means <i>familiar </i>a not <i>simple</i> and that it is a trap because it drives us away from the other (in small increments I would add).&nbsp; He is insightful when he talks about things that are source of complexity.&nbsp;&nbsp; He is funny, but missing the point in his critique of Agile.<br /><br />The development sprints he attacks are not about doing the bulk of the work - they are about building a prototype on which we can test our assumptions.&nbsp; Without the understanding that we get from these prototypes we could simplify as much as we want but it would not change the fact that our solution solves the wrong problem.&nbsp; <b></b>Agile is not an enemy of simple, it puts a lot of weight to doing the <i>easy</i> - but not because this is the goal - rather it uses <i>easy</i> as a mean to get to the <i>correct</i>. <b>Agile is the answer to the paradox that we don't know what we should make until we already have a prototype of that thing.</b>&nbsp; I wish more developers cared about <i>simple</i> - but only after they know what is needed.http://perlalchemy.blogspot.com/2011/11/thesis-simple-antythesis-easy-synthesis.htmlnoreply@blogger.com (zby)0tag:blogger.com,1999:blog-36345871.post-3758600653897366632Tue, 01 Nov 2011 17:23:00 +00002011-11-01T10:23:24.213-07:00Notes on the Synthesis of FormAccording to Wikipedia the origin of&nbsp; <a href="http://en.wikipedia.org/wiki/Design_pattern">Design Patterns</a>&nbsp;lays in the Pattern Language ideas by the unorthodox architect and philosopher <a href="http://en.wikipedia.org/wiki/Christopher_Alexander">Christopher Alexander</a>, but his earlier work also used to be widely read by computer scientists:<br /><blockquote class="tr_bq">Alexander's <i><a href="http://en.wikipedia.org/wiki/Notes_on_the_Synthesis_of_Form" title="Notes on the Synthesis of Form">Notes on the Synthesis of Form</a></i> was required reading for researchers in computer science throughout the 1960s. It had an influence<sup class="reference" id="cite_ref-naur_7-0"><a href="http://en.wikipedia.org/wiki/Christopher_Alexander#cite_note-naur-7">[8]</a></sup> in the 1960s and 1970s on programming language design, modular programming, object-oriented programming<a href="http://www.blogger.com/goog_2090500000">, </a>software engineering and other design methodologies. Alexander's mathematical concepts and orientation were similar to <a class="mw-redirect" href="http://en.wikipedia.org/wiki/Edsger_Dijkstra" title="Edsger Dijkstra">Edsger Dijkstra</a>'s influential <i>A Discipline of Programming</i>.<sup class="reference" id="cite_ref-8"><a href="http://en.wikipedia.org/wiki/Christopher_Alexander#cite_note-8"></a></sup></blockquote>The solution to the design problem that he proposes there does not look too attractive now, but his models, his metaphors, his insight into the design process - it's all still relevant and spot on.&nbsp; I am surprised that the Agile movement does not quote "Notes" as one of their foundation texts.<br /><br />http://perlalchemy.blogspot.com/2011/11/notes-on-synthesis-of-form.htmlnoreply@blogger.com (zby)0