If you will be driving to YAPC you’re going to need a parking permit of some kind. The hotels in the area all have their own parking ramps that you can park in. Likewise if you’ll be staying at the Lowell Center it also has it’s own private parking. However, if you’re driving in each day either because you live close, or you’re staying at a hotel too far from campus to walk, then you’ll need to get yourself a campus parking permit. They are $13 per day, and must be reserved no later than June 5th, 2012.
This Unicode stuff tried to drive me crazy, hopefully I'll record something useful here because the docs are a bit too intricated to understand.
The underlying assumption is that data is "moved" using utf8 encoding, i.e. files and/or stuff transmitted on the network contain data that is utf8 encoded. This boils down to the fact that some characters will be represented by two or more bytes if you look at the raw byte stream.
There are two ways you can obtain such a stream in Perl, depending on what you want to play with at your interface: string of bytes or string of characters. It's easy to see whether a string is the first or the second, because it suffices to call utf8::is_utf8:
The name is not very happy, in my opinion, because it tells you whether Perl has activated its internal utf8 representation. I would have preferred to have something called is_characters or whatever.
With over a week gone since the end of YAPC::Europe 2011, I'm please to see we already have 102 Conference Survey responses and 541 Talk and Course Evaluations submitted. This is once again a fantastic start to the responses and very much appreciated. However, there are still a further 165 who can still submit their Conference Surveys, and everyone still has time to submit feedback to the speakers of the talks and courses they attended.
If you haven't received your keycode email, please contact me and I will resend it. You still have 3 weeks until the close of the surveys, so please try and take some time to complete them. It really does help to improve the conferences for everyone.
For those interested in the results of the YAPC::NA 2011 surveys, although the speaker feedback has been sent out, I had to postpone my work on the Conference Survey due to some CPAN Testers issues and my attendance at YAPC::Europe 2011. As such, I am now preparing these results for the YAPC Conference Surveys website and hope to have an announcement within the next few days.
OpenMake Software is the DevOps Authority providing an enterprise scale DevOps framework for streamlining the build, test and deploy life cycle. Our solutions enable customers to reduce software development cycle times, improve communication between development and production control teams, increase developer productivity, and provide management with actionable audit and traceability reports. We go beyond what our competitors can offer by providing developers and production control a secure and dynamic operations framework that does not depend on brittle static scripts. Our solutions deliver on-demand cloud based server provisioning, environment configuration management, dependency management and continuous integration. Over 100,000 users at 400 companies worldwide rely on the DevOps framework from OpenMake Software.
While my department at $work isn't strictly R&D, we still do a lot of development work. I'd dare say we average a rather healthy amount of code, taking into account we also try to be rather minimal. Code is simply a means to an end, it is not your goal.
We get to write a lot of code that interacts with our systems, and a lot of duplication is achieved by mistake. Sometimes it's stuff people don't realize is indeed duplication, or they think it's unpreventable. I've decided to tackle this. I've presented some of my findings at Weborama after giving my Moosetalk, and they really enjoyed the ideas, and I've decided to write about them here as well, in more detail.
Since this is a lot of text and I hate reading a lot at a single time, I decided to parcel it out to smaller portions. This part will focus on refactoring schemas.
One of the great things about open-source software is the ability to reuse
handy classes written by other people. But sometimes, you find yourself
using a class that doesn't have quite enough features for what you're trying
to do. What's the best way to deal with that sort of situation?
One option would be to monkey-patch new code into the class you're using —
just add extra subroutines to the original namespace. But unconstrained
monkey-patching has consequences that make it extremely hard to use in
practice. So the usual alternative recommendation is to subclass the
upstream code, add the new methods in the subclass, and then ensure that the
rest of your program always uses the subclass in place of the original. But
that approach has two flaws. First, it can be awkward to make sure your
subclass is always used in the right places. Second, it doesn't actually
fix the problem: you can still experience all the same issues as with
monkey-patching!
I gave a talk on this topic at this year's YAPC::EU in Rīga, and
it's getting a repeat (and extended!) outing at the inaugural Dynamic
Languages Conference today. But if you'd like to read the full
details, the corresponding paper is now on my website.
I’m going to do a rare but unapologetic plug for a company that is not sponsoring YAPC: Amtrak. About a month ago I mentioned that Amtrak is a viable means of travel for YAPC::NA 2012. However, I didn’t mention how absolutely awesome it is. I’ve used it for a few trips recently, and I’m a complete convert from air travel.
Here are the benefits of traveling via Amtrak that immediately come to mind over any airline that you might pick:
I've been working on creating better sugar for event-driven systems in Perl– specifically, AnyEvent powered things. AnyEvent, and the modules it bundles, encourage a function based callback API, with at most one event listener per callback. Third party modules either follow that model, or the one presented by Object::Event, either using it directly, or implementing something that looks similar, but doesn't work the same.
What actually drove me to do this was exploring Node.js and its event API, which I find much more pleasant then any of the prior art on the CPAN.
So as such, I created a module, On::Event, which is on the CPAN now in a preliminary form. I've been toying with renaming it to ONE, however, as you can see on Github. The resulting API looks like this:
Earlier this year I was frustrated with Salvador Fandiño García's otherwise excellent Net::SFTP::Foreign package. It was in almost all respects the best choice for my current project at work, but the then-current version required me to check the return values of method calls for success or failure, and then use an error method to get any reasons for failure that might be waiting. The rest of my code used exceptions courtesy of Try::Tiny, and having to write three lines of boilerplate code for every SFTP call was getting annoying.
Thus was born Net::SFTP::Foreign::Exceptional, a very thin wrapper around Net::SFTP::Foreign that proxied all public method calls and then used a Mooseafter method modifier to throw an exception on any errors. (It originally used subclassing instead, but Salva set me straight on that and the less said about it the better.)
Padre 0.90 is a very important release in the maturity of the Padre IDE, as it represents the closest to what you might call a Beta that we've produced.
And it's certainly the best and most stable release since late 2010. But looking forward to 1.0 there's one glaring project-level issue left.
Once we do a "stable" release, we should finally be aiming to achieve fairly decent back-compatibility. And Padre has definitely tossed aside back-compat in exchange for faster development at every opportunity so far.
So if we're going to do a 1.0 release, we probably should take one final pass over the major APIs and break them horribly so that we have APIs that we're happy to support for a long time. And this is the major focus of the next 0.92 release.
One of the most important of these is Padre::Task, which is the API we use to run things in the background.
By now you’ve probably already seen the spectacular location where we will hold the banquet for YAPC::NA 2012. However, even the best planning can’t stop the rain from pouring down occasionally. So we’ve also secured an equally beautiful location indoors in case of rain. Our backup location is the Alumni Lounge in the Pyle Center.
objdump (otool on osx) is a program to examine a binary.
To examine perl run the command
objdump -D /usr/bin/perl |grep -A40 main.:
Interesting to see the function call
objdump -D /usr/bin/perl |grep -A400 main.: |grep call
to get the output in intel syntax add the option -M
objdump -M intel ...
GDB
for the following c program
main() {
printf("hello world \n");
}
-g flag to give gcc access to source code
gcc -g prog.c
gdb commands to debug a c program
gdb -q a.out
set disassembly intel
list
break main
run
disassemble main
to dump a string stored in memory
x/s 0x... (memory address) in this prog we can check the string hello world stored at instruction mov
debugging perl
- Get the latest bleadperl from git
- Configure and install perl with debugging support sh Configure -DEBUGGING=both
gdb -q /usr/local/bin/perl
set disassembly intel
break main or break line number
nexti or n to step through
s to step through a subroutine
If you live in Wisconsin or Minnesota another travel option available to you is Badger Coaches. They have daily service from Minneapolis, La Crosse, Whitewater, and Milwaukee to Madison, and they drop off 200 feet from the YAPC::NA 2012 conference facilities! A round trip ticket from Minneapolis will set you back about $75. One of the cool features is that most of the Badger Coaches have power outlets in every seat. So if you cling to your laptop like I do, then you’ll be able to stay charged up and working the entire time.
We will use this blog to keep you informed about our activities...
But who are we? We are the Frankfurt Perlmongers. We have our social meetings on the first Tuesday of a month at the MoschMosch noodle bar. As we have no tech meetings during the year, we organise a small workshop at the end of the year.
We applied for this year's yapceu, but Riga was elected. And they did a fantastic job. About 300 people were in Riga to listen to many Perl talks, meet other people and have fun.
We decided to apply for 2012 again and we hope we can welcome at least as many people...
There is neither a venue nor a date we can announce, but as soon as possible we will publish these information on several channels.
If you have any questions please send an email: questions@yapc2012.de
Further to my recent work on Params::Validate::Dependencies, I wanted to make the code-refs returned by the magic any_of / all_of etc functions somewhat self-documenting. And I've done it. However, there's quite a bit of boiler-plate in lib/Params/Validate/Dependencies.pm as a result. For example, I had to write: if($DOC) { return $DOC->_doc_me(list => \@options); } four times, and define four almost-identical classes.
Boiler-plate is Bad. So I then got rid of it. Unfortunately I got rid of it at the expense of depending on PadWalker, which is Crazy Shit. Do you nice people think that depending on PadWalker is a price worth paying?
Additionally, I also got rid of some not-quite-reblessing magic by using multiple inheritance. Again, is this a price worth paying?
In 2004 I started an Acme module, to simulate (interpretate) Lisp written as Perl list references. It is completely useless and is just taking space on my CPAN module list.
If anyone has any interest on it, please let me know and I'll hand it off.