I don't use it personally, but I've heard good things about it and a lot of people I know use it.
]]>With that in mind, for this to be successful we as a community have to go all in. Doing a rename like this in a half-assed fashion will fizzle out, and end up as wasted effort in a year. We need to give it an extreme amount of energy so it gets over the tipping point and takes on a life of it's own.
This means more than making a pretty logo, changing the version string, and saying "yay perl". It means making noise. Lots of noise. No half-assed "ironman" blogging thing that generates little interest. It means well designed, good looking documents and materials that have a consistent message, feel, and style.
It means a full-on rebrand with corresponding marketing blitz. It needs a Benevolent Dictator who knows branding and gets things done.
If you know what you are getting into, then I'm with you 100%. So yes, I am volunteering to put the effort in - if others are with me.
]]>I thought the wider perl community would appreciate having a look at my slides. As always, it would make more sense to hear me talking - but this gives a good idea as to what the talk is about.
If anyone wants to invite me to speak at exotic locations around the world, I am available ;)
]]>I've just implemented it myself. Looking forward to checking the results in a few months.
]]>I do think, for practical reason, the modules in the repo should be directly loadable by Perl (e.g. using 'perl -Ilib') but this is not always possible: for example since I use DZP::OurPkgVersion, my modules in the repo only has '# VERSION'. Code that tries to 'use MyModule 0.123' will fail.
I oversimplified a little... Like you I think that the module in the repo should be directly loadable by perl. That's why I use a dzil plugin that takes the `$VERSION` from the module. Rather than specifying the version in dist.ini and having a `#VERSION` comment in the module that gets replaced on release. My way means that you can `use MyModule 0.123` with the module in the repo and it will still work.
Some items in a build are auto-generated by dzil (meta.json, Makefile.pl, etc) - so I don't count them as part of the "module". What's important to me is that the perl file you get from the repo, and the perl file you get from CPAN are identical.
(Note, this is just my opinion. I'm not suggesting it's the One True Way™)
I believe that the module that is in the repo on GitHub should be identical to the one that you can download from CPAN, down to the comments and documentation.
I have my own pluginbundle that I just started using - https://metacpan.org/module/Dist::Zilla::PluginBundle::JAITKEN
I update the $version
in my main_module. D::Z::P:: VersionFromModule extracts the version from there, so I don’t have to update it in my dist.ini as well. Before I used this module I had forgot to update it in both places before… Ooops.
I use http://semver.org for my version numbering philosophy.
I update Changes by hand. I agree that extracting that from git commits is a Bad Idea™
I run dzil build, and pull the generated-from-POD readme.markdown out of the build, replace all “search.cpan.org” links with “metacpan.org” links (I should automate this step…). I then commit this in the root of my GitHub repo, so I have a nicely formatted readme when someone visits the GitHub page.
dzil release… And wait.
Once I get the email that indexing was successful, I push a tag to the GitHub repo. I don’t want to tag a version if there was an error on uploading to CPAN / indexing, so this step is manual.
I then retweet the announcement of my module release from cpan_new to the few perl people who follow me and care :)
After a few hours, I will install my released module (and any other outdated ones) to my perlbrewed perl with:
cpan-outdated | xargs cpanm --sudo
All in all a pretty similar process, but with less automation. I don’t think archiving releases is necessary. The CPAN is an “archive” after all, and I have my GitHub and local git repos. If my local HD dies, I still have my generic system backup, AND the remote repo on GitHub.
]]>Sad to say that I fall foul of a few rules presented here through ignorance. How was one supposed to know not to end an abstract with a full stop? Now it's clear, and all is good with the world!
]]>It's very useful for someone like me, without a background in computer science. I had only a vague idea of what a "linked list" was.
Looking forward to more :)
]]>Can you provide more details about what went wrong? I think data-loss on that scale is too large an issue to explain away with a vague "unfortunate side-effect".
The time you spent building & promoting it, plus the time people spent eagerly filling out their profiles needs a more detailed explanation to restore confidence, I think.
I will say though, InnoDB COUNT() is not in itself "slow" - COUNT() without a WHERE clause is the slow one. The queries you mention have WHERE clauses, and thus shouldn't be orders-of-magnitude slower. It's also slower than MyISAM because it's the correct value. MyISAM COUNT() is just an approximate value, not guaranteed to be accurate.
@Carey Tilden - https would be the way to do that. If you calculate the md5 hash client side and use that to authenticate with, then the md5 hash is the password, and you're effectively storing plaintext passwords (or storing a hash of the hash of the actual password)
General rule of thumb when it comes to crypto is to not try and do it yourself. Pick a library, and use it.
]]>In light of recent database hacks (MtGox, Sony, etc) - How to safely store passwords is at the front of every developers mind.
Almost every dev knows that storing plaintext passwords is a bad idea, but most don't realise that storing a SHA hash should also be considered a bad idea.
The SHA + salt pattern has been widely adopted, however modern hardware can brute force such hashes in a reasonable time using CUDA. In the near future it's not inconceivable that arbitrary hashes could be brute forced in seconds.
Bcrypt solves the problem of hardware increasing in power, rendering your chosen hashing function obsolete. I suggest reading How To Safely Store A Password, by Coda Hale for the hairy details.
To use bcrypt in perl, you can use Crypt::Eksblowfish::Bcrypt.
To help people follow these best practices, I have wrote a Dancer plugin that simplifies created and verifying bcrypt hashes. Dancer::Plugin::Bcrypt. Any feedback is welcome :)
]]>It was really easy :)
]]>It's a worthy cause.
]]>