It’s the first Tuesday of the month, so that means it’s YAPC::NA Planning Meeting time. If you’re in the Madison area, or don’t mind a drive there is a YAPC planning meeting tonight at the Essen Haus at 7pm. As always the food and beer are sponsored by Plain Black, and the room is sponsored by Essen Haus.
We’ve got a lot to discuss so the meeting will probably last until around 9pm, but you’re free to come and go as you please.
I'd like to find an alternative to the term "technical debt", but I doubt I could convince people to adopt it. Technical debt is so ingrained in the programmer's consciousness that we seem to confuse metaphors with synonyms. Metaphors are to synonyms as transvestites are to my wife (and that's an analogy I'm sure she's going to bring up over the dinner table).
Technical debt bears a resemblance to actual debt, but it's not the same thing. Like actual debt, it's accrued in the same currency (skilled labor over time) that must be used to pay it off. Like actual debt, it's often desirable if you need something now and can't wait for it.
We were discussing in email at work when Abigail put the nail in the coffin of the "technical debt is actual debt" debate. Specifically:
Sometimes it's OK to default on technical debt (code rewrite, proof of concept, business requirements change, and so on)
Monetary debt has a schedule on which you must pay it. Technical debt does not.
TL;DR version
"Perl has many \@grammar."
Perl is inspired from english fucking grammar, *not* english fucking language.
You see what Ich did there ? I used the word "fucking" two times. In both instances, I placed it between two different words. The communicated result is free fucking emphasis.
The idea of adding *fucking* in between two words for emphasis is a very interesting principle.
my fucking lunch.
my fucking life.
bang fucking bang.
The fact that it can be placed between two arbitrary words is *important*.
In fact, the idea of using '*' around words is also similar to THE idea of emphasis.
In the first case, we used infix notation and in the second case we use the circumflex notation.
And that my dear world, is a grammatical principle. It is a structural principle. It is a generative principle. It's inorganic chemical experiments for alphabets to do interesting things.
Even if we validate user inputs on client-side according to client-side form validation spec. defined in HTML5, we still need do same thing on server-side. It results that there're redundant validation rules around.
I wanna make a proposal; How about regarding client-side form validation as some common format for describing validation rules both for client-side and server-side?
This distribution consists of 2 parts modules below:
HTML parser to extract validation rules from given HTML file/string.
Plugins for existing validation module (for FormValidator::(Simple|Lite) so far, because I usually use it).
Caveats: This module hasn't supporte all the attrs defined in HTML5 spec.
chromatic will be giving a talk at YAPC::NA 2012 that he describes as:
Perl 1 was a quick and dirty tool intended to solve problems with minimal ceremony. Perl 5 continues that proud tradition and extends it with our amazing CPAN.
Yet sometimes our amazing tools aren’t what we need. Sometimes we make more work for ourselves. Sometimes the monolingual purity of our conventional orthodoxy gets in the way.
Sometimes solving a problem the best way (performance, ease, simplicity, safety, schedule) means doing it the wrong way.
I’ll show examples from real projects, deployed to real users, and explain why we chose to do things the wrong way. Potential examples include:
* HTML parsing * Database updates * Caching and the lack thereof * Avoiding rework * Error handling * Queueing
October was a rather quiet month publicly, but behind the scenes there has been a number of fixes, improvements and discussions.
The most notable fix was getting the summary emails running again. It is still not perfect just yet, but I'm hoping that the ongoing fine-tuning will reduce the bouce-backs and faults that I'm currently seeing. The configurations are all from what was in the database at the end of August, so apologies if you've wanted to change these. The configurations are normally exposed via the Preferences website, but as the SSL certificate for the new server hadn't been approved it has a little longer than anticipated to get it up and running again. GoDaddy have now approved this and it's all ready to go, so I'm hoping this can all be sorted in the next few days.
use signatures;
use Path::Class;
file( 'file.txt' ) ~~ sub ($f) {
say $f->basename;
say $f->slurp;
};
This style and syntax is reminiscent of Python's with and Ruby's do, and, for this use case in particular, feels a bit more natural to me than right-to-left, functional-style Perl5:
QR Code Scanner Pro is one of the better QR Code readers for Blackberry. Most importantly, it handles vCards. Since we’re using a lot of QR Codes at YAPC::NA 2012, do yourself a favor and get QR Code Scanner Pro, if you’re a Blackberry user.
This posting series relate to wishlist for existing modules. Some items are serious, some are not. I have not created a patch or submitted an RT ticket for the items, I'm posting them first to see other people's take on things.
1. Parallel cpanm. Last time I checked, there's a github issue on it. Ever had to install 200-300 modules on new servers? Without -n? Not for the terribly impatient. I suspect this is best implemented by a wrapper for cpanm.
2. DateTime->from_ymd(). It irks me that I have to write DateTime->new(year=>Y, month=>M, day=>D) everytime or (worse) having to use one of the DateTime::Format modules for this simple task.
In the past week or so, there has been a lot of discussion about improving the Perl tutorials. I think this is a great idea, and I even think I have something to contribute. Much of my work has been to allow for more scientific computation with Perl, including using PDL.
In order to start making a “Perl for Science” tutorial site, including some non-science Perl beginning material, I wanted to find a CMS, written in Perl (I can’t have a Perl tutorial site written in PHP!!) and having built-in code syntax highlighting. I couldn’t find it. Then I decided I had wanted a reason to try Mojolicious, so maybe this was it. I could write a template for tutorials and populate then with content using PPI to provide highlighting.
Since Mojolicious::Plugin::PPI didn’t exist yet, I made it up, based in large part on PPI::HTML. It is still rough around the edges, but I thought I would post something here to get some comments. I’m thinking about trying PrePAN too, but I haven’t gotten to it yet.
P.S. The tutorial site isn’t up yet, and may not be for a little bit. Of course I will post here when it is.
Because its an easy and modern way to share information. Nearly all of the attendees will have either a feature phone or a smart phone capable of reading QR codes.
Will QR codes be the only way to get info at YAPC?
No. We'll, of course, share the URLs and other info contained within them as well.
Will QR Codes be optional on my badge?
Here's how you opt out of a QR Code on your YAPC::NA 2012 badge.
Get a marker (you can borrow one from a YAPC staff member)
Take the cap off the marker
Draw a zig-zag on your QR code
Put the cap back on the marker
Give the marker back to whomever you got it from
Of course you might also not want to do that since YAPC is a social conference and you might actually want to make it easy to share your info with other people at the conference.
Did you know that QR Codes are evil because _____FILL_IN_THE_BLANK_REASON_____?
Welcome to 2012. The world's going to end this year anyway. Why do you care?
While I generally like Ocaml (as some of you may have guessed), there is one pet peeve of mine with the language: record fields names are module wide rather than record specific. For example:
type t = {
blah : int
}
The record field blah is now a module wide name so I cannot reuse it. Thus, field names that happen to be useful in two contexts are not allowed. Although, to be honest, having two record names the same is probably a sign of a refactor point.
It was exactly 1 year ago today (Nov 3, 2010) that I registered the metacpan.org domain name. Over the course of this year, the project has gone from a couple of guys writing some code to a true community effort. MetaCPAN is steadily being adopted by Perl developers around the globe and it is steadily gaining in functionality.
Together we've created a free, open, collaborative project which makes new tools available to CPAN lovers everywhere. The API has spawned some cool and very useful projects. The web site has spawned some much needed functionality in the form of diffs, syntax highlighting, author profiles etc.
Submit a talk for YAPC::NA 2012. We’re especially interested in talks on real-world Perl apps and quintessential Perl 101 talks, but we’re open to any ideas you have.
DBD::Firebird 0.9 has been released with a create_database method, using the isc_dsql_execute_immediate call. This means you can use DBD::Firebird to create a database without depending on the presence of a binary on the filesystem, which was the old way of doing things. Lots easier!
I'm creating a Perl Bibliography to go along with the other Bibliography booklets on O'Reilly's site. At OSCON as part of a Safari Books Online promotion, there were thin, real-paper booklets listing the books (from all publishers) in particular categories. They are also available as free downloads, like the Python Bibliography Perl didn't have one, although there was nothing nefarious about that; it just needed a champion.
If you'd like suggest a book, help with the production, and so on, let me know. This is an all-volunteer thing, even on my part. I think we can make this Creative Commons too, but my interest is specifically to put something on the O'Reilly site.
Maybe someone would like to sponsor a print run to hand out at YAPCs. :)
Frameworks are like declarative programming systems built over a language. They are not general, and they don't always tell you this, which is _clever marketing_ on their parts.
I have been burned by _clever marketing_ enough number of times so as to hate them.
Declarative systems are good, but when they are bad it's terrible. And they are not refactoring friendly, but copy paste friendly.
For me declarative programming languages/systems are hard to learn, because the "generality" is lost by the jump to declarative programming. Declarative programming languages are just one workaround piled over another, over another, over another ...... ad nauseum.
Look at the evolution of html ! It's beautiful to look at but what is underneath is terrifying. That's the same for every framework.
But why are jquery or Moose, which describe themselves are frameworks, so good to use ?
Here is my 2 cents worth.
1) They are not frameworks that dictate the program flow, but they are facad's s that _simply_ your workflow.
2) They do one thing and one thing well
3) I think the word toolkit better suit's them.
The same is equally valid for the new breed of web frameworks like Mojolicious, Symphony2, Sinatra Hope they takeover web development than what is out there.