rakudobrew is similar to perlbrew, but it's for Rakudo (a.k.a., Perl 6), the Perl-inspired language that we've all come to have a love/hate relationship with. I urge you to try it out, but first, some interesting new developments that you should probably know about.
After having read yet another tutorial about CPAN::Mini, I once again had the same thoughts:
This time, I tried to change it. Having thought about it every time I read a post about CPAN::Mini, I was prepared a bit. I planned a feature set that could be completed eventually some day in the future. The result is a working GUI where CPAN::Mini can be configured and executed.
Have a look:
If you're looking for a configuration file format, you might want to try IOD (short for "INI on drugs"). IOD is basically INI, with more precise specification and some extra features. If you are not using any of the extra features, you're practically using the good ol' INI format.
IOD tries to capitalize on the INI's popularity and simple syntax, and on top of that tries to define more precisely the format and to add some features that makes it more convenient and powerful to use.
Format is more precise. Because there is no single, official specification for INI, variants emerge and they support different set of features with different behaviors and incompatible syntax. IOD tries to define things more precisely, for example:
Loved YAPC::EU::2014? Hated it? Perhaps the conference would have been perfect if only we'd done X? What was your favourite talk? Could some talks have been improved?
You should have received an email from Barbie with an invitation to complete the YAPC::Europe 2014 Survey:
As an attendee of YAPC::Europe 2014, we would like to invite you to participate in the online conference surveys. Whether you are an attendee, speaker or sponsor, we would like to get your feedback regarding any talks and tutorials you attend, as well as the conference itself, with the aim of helping to improve the conference experience for future attendees.
Please shout at the organisers or email barbie[at]missbarbell.co.uk if you have any problems completing this, or did not receive an email with your keycode!
Only two weeks until SPW 2104. :-)
There are still some seats free. The organisers would like to ask for timely registration to make it easier to buy food, drinks and appropriate amount of fun. Inadvertent last minute show-ups only get water, dry bread and seats in the hallway. ;-)
Attendees, please leave your preferences and allergies here, so that our kitchen team can try and take these into account. This is especially important for the attendees dinner, taking place at the venue, but also for the lunches and coffee breaks.
Also, and especially if you are from Switzerland: Help tilt the Kickstarter Campaign for brian d foy who wants to work for his expenses and is going to teach "Mastering Perl" after the workshop, in Switzerland. The campaign is well underway, but could use a little more love, especially local love.
See you in 2 weeks at the Flörli in Olten.
Thanks to our sponsors:
www.leanux.ch | www.perl-academy.de | www.oetiker.ch | O'Reilly | WSIWLT GmbH
Don’t get me wrong, I really, really, really appreciate effort put into making something as small and efficient as possible.
However, it seems like we have a recent trend of using ::Tiny for things that do not meet the actual criteria of ::Tiny.
That is bad because seeing ::Tiny gives a certain expectation that, when not met, could be surprising, even bad.
Just because it is way less bloaty than something, like say, Moose: still not necessarily “::Tiny”.
Here are the rules Adam Kennedy originally defined for what ::Tiny means:
If you have a module with ::Tiny in the name space then please either make it ::Tiny or rename it.
Thanks!
/rant
Just while I was having a shower, the hotel had a 5-minute power cut. I decided to walk down the stairs to breakfast.
Another day of two breakfasts, one at the hotel and one at the conference venue (even more Баница) while meeting everyone.
Today I've mostly stayed in the "Devops" track as I've been doing a lot of web operations recently.
First talk of the day: SyContent - Content in the Cloud with V8. Torsten took us through the history of content management systems. He explained how he thinks content management should work, with Perl, PHP, static JSON files and V8.
Then Docker with Perl - an Introduction where Denis explained what Docker is and how he suggests we use them with Perl, although he doesn't run Docker in production yet. He explained that it really comes out of a DevOps culture. I currently use Docker to package the applications on my personal servers, so perhaps I'm a little too experienced for this talk. I particularly like the Docker workflow.
In Perl, hashes are typically used for two sorts of purposes: maps (where the hash key acts as an object identifier) and dictionaries (where the hash key acts like a field name). A quick illustration of what I mean by this:
# Maps my %ages = ( alice => 24, bob => 25, carol => 31, ); my %email = ( alice => "alice@example.net", bob => "robert.smith@example.com", carol => "c_jones@example.org", ); # Dictionaries my %alice = ( age => 24, email => "alice@example.net" ); my %bob = ( age => 25, email => "robert.smith@example.com" ); my %carol = ( age => 32, email => "c_jones@example.org" );
These are two different styles of using hashes. Sometimes one is useful, and sometimes the other is. Sometimes neither is better and your choice of one over the other is fairly arbitrary.
Types::Standard contains a type constraint called Map which is useful for validating references to the first kind of hash. (I copied the idea from MooseX::Types::Structured.) But today I'm mainly going to talk about another type constraint: Dict. (Yeah, I copied that one too.)
(cross-posted from blog.tobez.org)
Ignat Ignatov talked about physical formulas.
When I was planning to attend this talk, I thought it is going to be some sort
of symbolic formulas computation, possibly with an analysis of dimensions
of the physical quantities.
However, despite my (a bit long in the tooth) background in physics, I did not
understand a word of it. Apparently, some sort of unification of physical
formulas, not entirely unlike the periodic table in chemistry, was presented, with
almost no comprehensible details and with scary words like co-homology and
algebraic topology. The fact that half of the slides were in Russian, while
irrelevant for me personally, probably did not help matters for the majority of
the people in the audience. I did not expect any questions at the end of the
talk, but there were at least two, so I was probably wrong about general
level of understanding in the audience.
In my previous post about perlcc next steps I talked shortly about my current project, Perfect::Hash.
In my previous blog post I wrote a lot more about Time::Moment, than appeared in the post (could have been my mistake due to a preview and error and a incomplete copy and a paste, but still very inconvenient). So I have decided to break down my original blogpost in several blogposts.
Time::Moment implements a subset of ISO 8601 (known as 4.3 Date and time of day, 4.3.2 Complete representations), Wikipedia has a good article regarding ISO 8601, but it's not an authoritative source for the ISO 8601:2004(E) standard.
Time::Moment is capable of parsing any string that purports to be formatted in ISO 8601:2004(E), 4.3.2 Complete representation.
Such formats includes the following:
Combinations of calendar date and time of day:
Basic format:
20140808T003146+0200
20140808T003146.705971+0200
20140808T0031+0200
Extended format:
2014-08-08T00:31:46+02:00
2014-08-08T00:31:46.705971+02:00
2014-08-08T00:31+02:00
Combinations of ordinal date and time of day:
If ever you're unsure of how a type constraint has been defined, you can examine the string of Perl code used to implement it. For example, does an ArrayRef[Int] accept an empty arrayref?
my $type = ArrayRef[Int]; print $type->inline_check('$X');
(crossposted from blog.tobez.org)
When I came to the venue 15 minutes before the official
start of the registration, people at the registration desk
were busily cutting sheets of paper into attendees' badges.
Finding my badge turned out to be a tad not trivial.
This conference is somewhat unusual not only because it is conducted over the weekend instead of in the middle of the week, but also because the keynotes for every day are pushed till the end, even after the daily lightning talks session.
The welcome talk from Marian was about practical things
such as rooms locations, dinner, lunches, transportations
and so on. Then I went on stage to declare the location of
YAPC::Europe 2015 (which is Granada, Spain by the way).
After that Jose Luis Martinez from Barcelona.pm did a short
presentation of YAPC in Granada, and Diego Kuperman gave
a little present from Granada to Sofia.
A day of two breakfasts, one at the hotel and one at the conference venue (more Баница) while meeting everyone.
First big announcement of the day was that YAPC::Europe 2015 will be in Granada, Spain.
And then the first talks of the conference. I chose to attend Welcome to Auditing and toughening as part of the Security Development Lifecycle which was an interesting look at how hardening a system is just a small part of the security development lifecycle. John highlighted the importance of a threat model and how avoiding vulnerabilities as early as possible is the only way to go. He went though a few practical examples of where was the best place to fix
vulnerabilities.
Over sandwiches at lunch we had a little discussion about the compromises between fixing vulnerabilities and maintaining backwards compatibility.
The Wi-Fi has been a little spotty, but mosh make it usable.
Next up was Code I'm proud of: where Thomas explained lots of little hacks, from passwords and Bread::Board to microblogging.
We are hoping to live stream the conference which starts on Friday morning. We will have streams of all three tracks:
Hall Vitosha
Hall Musala
Hall Rodopi
Hope you can join us!
Let's say you want an attribute to accept a pair of numbers - perhaps a geographic co-ordinates [ 50.873, -0.002 ]. You could constrain the attribute as ArrayRef[Num], but that would accept an arrayref containing a single number, or eight numbers, or even a reference to an empty array.
With the Tuple type constraint, you can be more exact in expressing which values are acceptable:
isa => Tuple[ Num, Num ]
[ Cross-posted by invitation, from its home on the Ocean of Awareness blog. ]
Currently, in designing languages, we don't allow ambiguities -- not even potential ones. We insist that it must not be even possible to write an ambiguous program. This is unnecessarily restrictive.
This post is written in English, which is full of ambiguities. Natural languages are always ambiguous, because human beings find that that's best way for versatile, rapid, easy communication. Human beings arrange things so that every sentence is unambiguous in context. Mistakes happen, and ambiguous sentences occur, but in practice, the problem is manageable. In a conversation, for example, we would just ask for clarification.
It turns out that it’s quite hard to change Ukrainian Hryvnia back into your local currency. Apparently you need to get a special form to do it, which seems to be about as common as a Ryanair refund.
Given that quite a few of us aren’t that likely to return to Ukraine any time soon, it implies that there’s quite a lot of paper money sitting around various Perl monger’s desks, drawers etc, not earning its keep. For each individual it’s not much in value, but I suspect that all together it adds up to a few thousand Pounds/Euros/Dollars etc. Meanwhile, the Ukrainian central bank is very happy about all currency it got in return for selling us [its] bits of paper.
So I thought that it would be a good idea if we put the notes carefully to one side, and then all took them to Sophia next year, where at YAPC::Europe 2014 someone from Kiev can come with a big bucket, collect the money, and take it back to do useful things with it.
I assume that the intervening events have not made changing the currency any easier…
In any case I’ll be bringing my 70 along, and bulk88 has expressed interest to buy, should none of our attendants from the Ukraine want them.
So you have this Moo class, and it turns out what you really need for it is the StrictVersionStr type constraint defined in MooseX::Types::Perl. You could switch the class to Moose, but long term you want to stick with Moo.
Eventually you'll steal what you need from MooseX::Types::Perl, so you don't have the Moose dependency, but for now what you really want is to be able to use a Moose type constraint within a Moo class! What a predicament you've gotten yourself into! Type::Tiny to the rescue!
{ package Local::Eg5; use Moo; use MooseX::Types::Perl qw( StrictVersionStr ); use Types::TypeTiny qw( to_TypeTiny ); has version_number => ( is => "ro", isa => to_TypeTiny( StrictVersionStr ), ); }
blogs.perl.org is a common blogging platform for the Perl community. Written in Perl with a graphic design donated by Six Apart, Ltd.
