Hopefully, someone will use the blog post to write an actual doc patch, seeing as how this is undocumented.
I finally wrote A test for DZP::OurPkgVersion with the help of CJM. So I figure it's best to share the knowledge imparted upon me to all those who are writing plugins without tests.
Before we get started I'm going to advise that this test will only check the output that dzil built, if you need it to test anything more sophisticated, you'll have to learn more.
First you'll want to create a corpus repo like /corpus/MyDZTRepo with a basic minimal repo. This repo is simply a repo that you are using to test your plugin against, to make sure it works right. You put it in corpus so that if you have tests that you have to check in your corpus, those tests themselves aren't run when the test suite is run. The dist.ini doesn't need to contain anymore than the basic stuff needed to build. You .pm files need not have anymore data than what you're going to need to make your dzil plugin do its job. In the case of DZP::OurPkgVersion I only needed to test that the output found the # VERSION string correctly in a couple of scenario's. So that meant having # VERSION in the .pm's and [OurPkgVersion] in the dist.ini.
First DZT (Dist::Zilla::Tester) doesn't provide any tests of its own so you still need to use Test::More or some other testing framework. Next you need to initialize the tester object by telling it where the root of your corpus repo is. After that, unless you need to do other work, you can run $tzil->build so that the build is run.
So now lets slurp a file into memory so we can check to see if it was built right. You'll want to look in 'build/*' as the basic root of the build directory. So 'build/t/test1.t' if you need to slurp a test.
Now that we've pulled our build files into memory lets code up what the result should be. We can just do this with a simple heredoc, obviously you can do it another way.
Now that we've gotten that, all we have to do is compare the file that we expect dzil to output and the file that dzil actually built. This is just standard Test::More
Now let's take a look at it all together.
Pretty simple huh? Hope this means more dzil modules getting tested now. Including more of mine.
Although the criticism of Part 2 should be taken with a grain of XKCD Salt, and even the primary plaintiff admitted that it would take him 2 months to crack the final salted sha512. Usually your attacker shouldn't have your shadow file, and having stored them as anything less is just plain not secure. I will acknowledge it has some merit.
Doing a base64 transformation on hex only digits is a bad, idea, and does not have nearly enough possible combinations. Nothing is going to be more secure than random, but random isn't really recoverable, if you lose it. That's why I do some kind of transformation.
I believe that somewhere someone suggested that it would be better to convert from the binary digest into base64 as it would be more random than from hex. I believe this is accurate, but the method suggested was in Perl, which is kind of messy, and more importantly hard to remember. So I asked, on unix.stackexchange.com, how I could do this on the command line. Here's the answer I decided to accept:
Remember you should slightly modify the result in a way that you can remember in your head to make it random, and probably use something in place of the "date" command, since it's not reproduce-able.
Again: this is not meant to be as secure as random passwords, just secure enough compared to non random alternatives.
Today Joel Spolsky announced The results of the poll of whether ubuntu SE and unix SE would be merged, they won't. In short the Unix community was in favor of it but the Ubuntu community was not. Joel had this to say:
So, Ubuntu, Linux, I get it, it’s clearly not the same thing. If you love Ubuntu, we have a site for you. If you love Linux and Unix, we have a site for you. A Stack Exchange can’t work without a community that loves a subject, and love is very… specific. Fighting human nature is hard: the factionalism and fork-happiness of the Unix world has been a hallmark of that community ever since BSD vs. System V, and Stack Exchange can no more bridge that gap than we can unite the Judean resistance.
I am horribly disappointed in this decision, this factionalism doesn't help the cause, this set's precedence that it's ok in the StackExchange community to be a separatist. Arch Linux's bash must not be the same as Ubuntu's or Fedora's, and of course they've made so many changes to upstream Gnome as to be unrecognizable as such.
The main argument in favor of this separatist movement is that Ubuntu is for beginners, if that's so then why isn't it beginner.unix SE? What's a beginner anyways?
I'd dare wager that 99.999% (POOMA) of all Linux users are windows Power users, veterans, and refugees. So what's a beginner? someone that doesn't know what Firefox is? No they probably do. Maybe they don't know where it is in the menu? I can see that... but I don't see how that can't be answered with a Screenshot and a Ubuntu tag on Unix SE. Maybe it's someone who doesn't know how to use the CLI? Well where do you define beginner from advanced? I realize someone reading there first shell programming Tut/Book/etc is a beginner, but are they no longer a beginner after that? how do you know you're not a beginner anymore? When you choose to move beyond Ubuntu? If I've been using Linux for 5 years and I choose to move to FreeBSD am I a Beginner?
Why is that the answer to a beginner from an advanced user isn't welcome? Is it good that beginner are exclusively answering other beginner questions?
In other news it looks like I may become a moderator ( temporary at least ) for unix SE.
I don't like the GPL anymore after the WordPressThemefiasco. I don't like the idea that a theme, plugin, addon, extension, whatever is 'derived' from the thing it's adding on to and thus must also be GPL.
If I build a deck onto the back of my house is that deck derived from my house? No! if I take the blueprints of my house and build another one that's 80% like it is that house derived from my house? yes. If I offer a painting service to paint houses and I offer people preexisting color schemes are those schemes derived from their house? should the manufacturer/contractor (whatever) be able to tell me I can't do that, or that I have to share my colorschemes (and how I mix my paint) with him? How STUPID, IMO. But that's what the GPL does, you can't help other people addon to their house without sharing it with the house builder.
Now I'm all for sharing source code back, and I think if you modify OSS you should have to give your source back. But if you don't modify it and you are just using the the public API, why should you have to give all of your code up for that? or more importantly why shouldn't be you be able to choose your own OSI approved license? I mean what if I have a GPL library, a Artistic Library and a BSD library I want to use to build an application, which has an API, must be GPL and so must everyone's apps that add to it. No you may not make a DWTFYWWI plugin, no you may not make a BSD plugin, no you may not release that code into the public domain, because the GPL says so, and I used a library that made me use it.
Well ya know what? I'm not going to use the GPL from now on. I need to find a new license that fits my needs (and will not be toxic to others).
Desire #1. He who modifies my code, and distributes it, must share his code (with me).
Desire #2. He who wants to use my API may do so (so long as he doesn't modify it)
Desire #3. He who wants to copy my code must share it, and any changes.
Desire #4. Some patent protection would be nice
Desire #5. letting users outside your organization utilize it counts as distribution (a'la AGPL)
I think the LGPL fits this bill, except for #5.
seriously why is it that you could optimize the internals of wordpress and make your own hosted blogging platform and you wouldn't have to share the changes at all... but with a theme you do...
Are there any other licenses I should consider or considerations I should make?
(honestly you don't have to agree with me about not liking the GPL here, this is just me)
Unix & Linux: I think it'd be more used than Super User and ServerFault for some questions.
Outer Join: A place to ask questions about databases and queries
User Interface: because this is something we could all do better with.
Please consider following/committing. esp the unix/linux one (since I don't think Ubuntu should get to have its own, while leaving the rest of us in the cold.)
I have been heavily criticized for criticizing, critiquing, and complaining about lack of quality in open source projects. I have done these things because I care, generally because I care about that specific project, or Open Source (or whatever I'm talking about) in general. I've been attacked, insulted, and sworn at. I've recently come to the realization that the community support that behavior, to the point that they won't stand up against those doing it. It is a very cliquish and tribal community, if you're in the in crowd you can do or say what you want, if not you'll be ostracized. I have been ostracized for years. I have decided to join the opinions of those I've been ostracized by, but also to accept my exile.
In order to discontinue my negative and inappropriate behavior, I have to stop caring. I choose now to not care about helping others who cannot (or choose not?) to help themselves. I will no longer complain about the problems of some projects, even those that I can and have provided fixes to the problems for. I will no longer fix problems that do not impact me. I will no longer tell people that they are misguided, no matter how much they are. I will no longer produce anything that doesn't help me. I have to become selfish and stop caring about the problems of others.
To this end I'm discontinuing my work on Arch Linux's AUR as it doesn't help me, CPANPLUS::Dist::Arch which does most of the work, is more than capable of doing this for anyone using Arch, the packages will be orphaned. In acceptance of my exile I am removing myself from all IRC channels (though I will continue to connect) unless I have a problem, that way I do not end up causing a problem, it seems even when I have a problem and try to limit it to that I end up causing one. I am going to ask that my blog be removed from the Iron Man 'competition'. I've been told that none of the work I've done is significant anyways, and thus my loss will not be a loss at all.
I will continue working on any project that has some benefit to myself, as my time is precious and I have a life outside of Open Source. I will only do so, however, if it doesn't require me to have an opinion. There is no point in pushing for a fix that I have a workaround for already, I will simply be seen as entitled and asking too much of other peoples time.
I can't win the fight by writing patches, or by helping people by answering questions, or sharing my knowledge publicly. So I choose not to fight, I choose to accept that I am not wanted and so I will leave.
Here I talked about creating a new catalyst project using a minting profile for Dist::Zilla. If you don't know how to create a minting profile read that first. I'm sure once you've tried that you'll agree that having a little bit more than the basics in a newly minted dist would be a good thing.
first we need to create our profile.ini correctly (note: if you've got [DistINI] plugin loaded you'll probably want to remove it) Now you can put any file in the subdirectory repo of your profile (if you leave out 'include_dotfiles = 1' then anything beginning with a . won't be included), and it can be a template using Text::Template. Dist::Zilla uses {{ }} for Text::Template Delimiters.
Let's start with adding a .gitignore file (if you're using git) we can create {profile}/repo/.gitignore the {{$dist->name}}* will exclude the directories and archives dzil creates on release and .build will of course ignore the .build dirctory.
Now for a more complex issue, creating a Changes file that has the the {{$NEXT}} variable in it to insert the date and such on build. Obviously you can format your Changes file however you want.
Now we want to create a much more complicated dist.ini All of the stuff between the first set of {{ }} is boilerplate mostly taken from the DistINI plugin so that we can use our settings from our config.ini, I really wish there were some convenience accessors for this. I also wish we had an arbitrary stash we could use in config.ini so I wouldn't have had to hardcode my username in this. I think it's all fairly self explanatory beyond that. Of course you can set up your dist.ini anyway you want. Also if you use this format you have to have your module's repo name on GitHub in camel case like it is on CPAN.
Next time, in promulgating your esoteric cogitations, or articulating your superficial sentimentalities and amicable, philosophical or psychological observations, beware of platitudinous ponderosity. Let your conversational communications possess a clarified conciseness, a compacted comprehensibleness, coalescent consistency, and a concatenated cogency. Eschew all conglomerations of flatulent garrulity, jejune babblement, and asinine affectations.
Let your extemporaneous descantings and unpremeditated expatiations have intelligibility and veracious vivacity, without rodomontade or thrasonical bombast. Sedulously avoid all polysyllabic profundity, pompous prolixity, psittaceous vacuity ventriloquial verbosity, and vaniloquent vapidity. Shun double-entendres, prurient jocosity, and pestiferous profanity, obscurant or apparent!!
** ** In other words, talk plainly, briefly, naturally, sensibly, truthfully, purely. Keep from slang; don't put on airs; say what you mean; mean what you say. And, don't use big words!"
I don't know where this came from originally, but I should also say... cut the technical jargon to a minimum. Not everyone knows everything you do and even if they know all the words laymans terms may be a better way of explaining it. Give an analogy, if they don't get it; Reduce it to the simplest possible terms.
P.S. I pissed someone off because I told them it wasn't my understanding that was the problem it was there ability to explain things simply, and then gave them a link to this. I did eventually get why X was a good thing in spite of the overcomplicated explanations.
For starters I'm not a super fan of interactive shell's for non-system shells. I don't see the point as much. When I first tried Devel::REPL I didn't like it at all, compared to every other interactive shell I've used (with the notable exception of Oracle's SQLPLUS, which is the worst shell ever) it was an unfriendly toy not worthy of mention. I couldn't go up in history, there was no tab completion, and all in all the default output was ugly no colors or formatting. I noticed in the docs
By default the re.pl program looks for (all of the following code goes in this file)$HOME/.re.pl/repl.rc, and runs whatever code is in there as if you had entered it at the REPL shell yourself.
and that re.pl has plugins, I also noticed some strange syntax and what seemed to be overly complicated code for just getting a few things working. Sure the file supports perl, but do I really want to write full perl programs in an RC file just to use plugins?
Well fortunately it's not as complex as all that. First thing you want to do is set some good perl defaults. Since this is our private shell might as well get all the current features of perl. Of course if you want to have other modules always accessible load them here to.
Now lets get some sanity into the shell by using plugins for REPL. It's really much simpler than the docs say. Wow that's way easier than what any of the documentation describes.
Ok let's look at some plugins. First if your typing isn't perfect you've probably noticed that you can't use your up arrow to go back in history, to fix this you can enable Readline support by loading Devel::REPL::Plugin::ReadlineHistory like so, This will allow you to up arrow to go back through lines you've previously typed, which you can then edit just like your normal *nix shell prompt. This one thing makes re.pl about 100x less annoying.
But I wish I had some kind of tab completion so I didn't have to type so much. Hey there's a whole set of completion plugins, lets enable those too.
So the Keywords Driver allows you to type pri< tab > and it'll complete print plus showing you printf just like your *nix shell. LexEnv will allow you to auto-complete your variable names and so on. There are a few more besides what I mentioned here.
Next I'll mention the Colors plugin. You may have noticed when you enter code such as my $var = 'blah'; say $var; you get the output
blah
1
or the output text and return code. well if you enable colors the return code is now in green making it easy to distinguish between output and extra info.
Last but not least I'll mention DumpHistory, enabling DumpHistory allows you to Dump your input history to the screen or to a file.
Now we have a fully functioning, 'user' friendly, perl shell.
Some might point out that using a hex digest limits the characters that will be generated too much, do this then.
echo -n "date" | sum | base64
So let's say you have to change your password every month. Pick a day, let's say the second Tuesday of the month. Since your memory sucks write this down "Pipes on second Tuesday @ 5:08!". Sounds like an event reminder right? Here's your actual password algorithm for this month. First you want to has the 'second Tuesday of the month'.
So what was the rest of that reminder for? Now you're going to make it as good as random, take the first 8 characters 'NTFhMTY4' and insert a pipe '|' at the 5th character, resulting in 'NTFh|MTY4'. Now you have a 'good as random, but recoverable' 9 character password.
Given if you work with really clever people they might be able to figure it out if they know you use this kind of process. But I'm sure having read this article and my previous one you'll come up with something even better, but just as reproducible.
UPDATE:
I do not believe that anyone can seriously prove (after having read both articles) that you could crack this with anything less than a brute force attack. Because I've suggested inserting 1 or more characters into the final outcome, chances are those are anything in the 94 printable characters of ASCII. Yes you might limit the end possibilities but after seeing passwords that most people have... this makes you a hard enough target that no one is going to bother. Basically all assumptions that using this is bad revolves around someone knowing exactly what you do (so in reality it's probably only bad for me).
I should also note that my personal system encrypts passwords with a salted sha512 and I'm having trouble find a password cracking tool that can even try to brute force that.
UPDATE:
oh and just in case you forgot... no one is trying to brute force your password. Remeber this XKCD
A few months ago we had an assignment in Web Server Admin to create a CGI page, of course the perl was just to print text not actually do anything more, but I decided to use CGI.pm just because I never had. The whole thing was nothing more than hello world.
and I thought, wow I can write all that html with just that? why can't I use that syntax as a templating language. Of course when I asked I got imbecilic responses of how bad CGI.pm was or how it used function calls is stupid. And I was put on to Template::Declare and another which I don't recall. Template Declare would be nice if it didn't require the templates to be in a Perl file.
At some point I discovered Haml, simple and shorter than writing out the full HTML, unfortunately it was still longer than the CGI syntax and whitespace sensitive. But I kept looking through it. it has variables, but no loops, conditionals, or includes. So for a templating language it's simplistic or immature. I got around to googling "Haml Perl" and found this on StackOverflow (of course without my post). I thought well, shouldn't be too hard to make Text::Haml into a Catalyst View or ... better yet a Plugin to Template Toolkit so we can get all the goodies Haml is missing.
Since Haml is whitespace sensitive you have to be careful about how you strip (or don't strip) whitespace from TT code. Obviously this is a simple example, I have no idea how well this works in a larger codebase, and since there's no XS module for Text::Haml I don't know how well it performs. I hope it's useful for someone though.
We need a page linked from Perl.org that says 'Get Hosted' (or something like that). The page will have a list of the top 10 Perl friendly web hosts on it. The top 10 will be determined by people with CPAN ID's voting it up or down (the use of CPAN ID's should prevent spammers from gaming the system like digg get's gamed). It could have in the listing, rank, # of positive votes, business name, site uri, technologies supported (e.g. cgi, fastcgi, mod_perl, plack, etc), and maybe starting price. Of course you should have a link to the complete list. Companies should be able to register themselves without getting a CPAN ID.
Just an idea for making it easier to find great Perl hosting.
I been thinking about it for a few days, and of course consider I know nothing about grammar parsing or how any of this works. I wish the my $var; syntax would go away... or at least be less necessary. In almost all cases you want a lexical variable and use strict; doesn't allow you to use $var anyways. So what'd I'd like to see is my become a mostly unnecessary reserved word, make $var a lexical variable by default, e.g. my $var; be the same as $var. my would only be needed for redeclaration's and back compat. It could be enabled with a pragma or something like use feature 'lexical';. There might be some reason I'm completely wrong or stupid, but this doesn't seem like a bad idea, and of course our, state, local would still need to exist.
UPDATE: the point of this would be to make variables lexically scoped by default as opposed to there current global default.
If you use git and you're past the tutorial and using it for an actual project, I suggest you take a look at the workflows manpage as well. It will give you ideas on how to branch, merge, rebase and cherry-pick.
This has been a public service announcement, that is all.
So I just recently finished reading Restful Web Services and decided I wanted to go back and play with Catalyst and REST some.
The original way to create a Catalyst skeleton is to run catalyst.pl MyApp. This creates a lot of nice files to get you started. dzil new basically does the same thing for a generic cpan module. Honestly, without any plugins dzil new isn't that useful. However, once you add Git::Init , you remove several steps from the creation of a new module and repository. Git::Init also makes your first commit of everything it added. I got to thinking why on earth would I want to do the following to get a cat module going and convert it to dzil.
catalyst.pl MyApp && cd MyApp
vi dist.ini # and add numerous lines
rm Makefile.PL README t/* # and maybe more since dzil is better at managing these
git init
git add .
git commit
when I could just be doing this
dzil new -p catalyst MyApp
A lot simpler huh? to get you started you need a few things but then creating cat apps will be easy.
first you can run dzil setup or if your version of dzil doesn't support that yet, you need to create the following ~/.dzil/config.ini file by hand obviously fill in your own credentials and license preferences. This file is pretty much needed for any dzil new operations.
Next you need to create a minting profile (not necessary for barebones doesn't do much for you). run mkdir -p ~/.dzil/profiles/catalyst/ (note: catalyst is arbitrary, it can be anything). now create a profile.ini in that directory. The only mandatory line in this file for this to work is the [Catalyst ...] one, I think you'll want the other two however. You also want to set AUTHOR="your name youremail@example.com since that's how Catalyst::Helper inserts it into its files (I'll probably work on fixing helper later).
Now you can just run dzil new -p catalyst MyApp. Hopefully, this simplifies your catalyst app creation a little bit.
Good patches are welcome, so are feature suggestions and bug reports. Also I registered it as Dist::Zilla::Plugin::Catalyst So if there are any other plugins that you think could be useful that are specific to Catalyst I'd be willing to add them.
Special thanks to Tomas Doran who helped me (ok... he wrote most of it) create this module.
Firstly I want to clarify a bit on my opinions of PluginBundle::USERNAME modules, as some comments there have inspired this post. I don't think you should use them because it makes it harder to disable plugins, and I think Robin Smidsrød put it best:
Mostly it is because the Dist::Zilla::PluginBundle::USERNAME doesn't actually say anything about its intention. It only says use Dist::Zilla as this person does, but what does that actually mean? If you don't know the person it doesn't really tell you anything.
I'd much more prefer PluginBundles that actually advocate certain types of standards or behaviors.
...
Essentially Bundle's like @Git and @Basic don't cause problems because they're generic well defined and contained within their distributions. A bundle that wasn't contained within its dist might not cause a problem if it's for a generic well defined purpose. I'd be in favor of a BundleQATests or similar so long as the author was considerate that some tests (PodSpellingTests) don't work well on some *nix distributions and isn't included in the bundle. But Something like @Xeno (my cpan username) would be my own special settings... who wants to use something that's only for me? and more importantly why would they ever think they have a right to bug something that the name itself implies it's only for me.
But another problem was brought up... code generation. Here's what Nilson said:
dzil is very nice, but I don't if I like the idea of different line numbers and files in the repository vs. the CPAN release. I'm still trying to fully digest this idea.
I remember one of the main mentioned drawbacks of source filters were the possibilities of error messages in the wrong lines. And now, everyone seems to embrace this without hesitation.
So to start dzil's generation isn't quite as bad as a source filter which will give you the wrong line number period, using this generation will still give you the right line number for the module being run at the time. It just means the cpan line number may not match the repo line number. I'm going to show you how to fix this, but you don't always have to. The most common place I've found problems with in code generation has been tests created by extending InlineFiles. In these cases you just want to go and bug the author of the Plugin. I think using these plugins is much better than writing your own EOL Tests, NoTabs, Critic, and Kwalitee etc. It helps keep your dist quality up without extra work, ultimately leaving you with just the responsibility of writing good tests that are specific to just your distribution.
Now on to making sure that your repository matches your cpan dist. The first thing you want to do is use [Git::CommitBuild] (if you're not using git look for something like it or write something like it) This will take all the generated output and commit it to another branch each time you build. Then make sure this branch is pushed to your public repository. I think the biggest problem this solves is having things like your README and your LICENSE actually be in your public repository (if your repo doesn't have a LICENSE... what's the legal situation?). If you're using github you can also change this to be the default branch to be displayed in the repo admin settings.
Next thing is don't use ::Plugin::Prepender This will evil-y insert lines at the beginning of your code which will definitely throw off the line numbers being output. It even seems to suggest using it to insert use strict; use warnings;. If you need output prepended to all files, I suggest writing a plugin that takes advantage of dzil new and maybe just write a script that you can fire off whenever you need to create a new file. This is the only module I know for sure that does this, but avoid ANY that insert actual code or prepend lines to your files (in a way that isn't added to your actual 'master'/'trunk' that should be patched).
POD can also screw up your line numbers, if you're using PodWeaver (or module that has similar side effects) with dzil, which you likely are. Perl Best Practices page 140 will save you here (actual quote pg 475 a summary chapter).
Keep all user documentation in a single place within your source file. [Contiguity]
Place POD as close as possible to the end of the file. [Position]
This includes the # ABSTRACT: my abstract here line. If you put the # ABSTRACT and any actual pod after the code then all the pod generated will be after the code in your build, and thus any line number errors will be correct. Of course this doesn't save you if your error is in the output pod, but I suspect that's not the original complaint anyhow, and there are lots of dzil plugins to help you keep your pod sane.
Essentially don't do anything that will change line numbers for the code in the resulting build output. Following this will ease contribution, and debugging; I do not believe it significantly increases maintainer load. Happy Hacking!
UPDATE:
just remembered... dzil inserts a BEGIN block... sigh... can't win for nothing.
the ; is a comment in ini, now dzil won't use that plugin. But people will say well you don't want to do that of course I want that plugin enabled. Here's why you may not temporarily. Casual user X has a bug in /your/ module that's using dzil, they code up a patch, and they want to run your test suite. The can't, because [pluginXTests] won't even install properly on their system due to a non perl dependency. They could have just commented it out, but now because you've used this PluginBundle it become difficult. They can't just comment it out.
They might be able to
[@Filter]
-bundle = @USERNAME
-remove = pluginXTests
IF they can get your bundle installed in the first place. This requires them find a way to install your Bundle without installing said broken module.
as I stated at the top my problem is with [PodSpellingTests] it itself isn't broken, but it's dependency Test::Spelling is on some systems, due to the lack of a 'spell' command.
Yes I know there's a workaround... I could just copy a shell script into my path that makes aspell or something work, but really that's not the right solution. No I'm not packaging GNU Spell for my system either, the other spell programs work much better (from what I've read).
Also I find modules with your own username in them to be fairly obnoxious.
If you'd like less code, can't we start making a few more generic Bundle's? I wouldn't minde seeing a Bundle for Tests, and maybe another one for other stuff. I think 1/3 of the lines in my dist.ini's are tests.
git was designed to be very flexible in its workflow. One of the things it was designed to do was handle email patches, since there are a lot of patches sent to and from the mailing list. This is a good thing, even if you don't have a mailing list, or you have your own bug tracker (in addition to RT), you can use RT to receive email patches from git. First you have to configure your MUA (mail client)(and go write a patch), some suggestions are given in git.git's SubmittingPatches document. If you like the CLI I suggest you use the git send-email command. I'm going to walk you through using it, but you'll have to learn how to set it up for your smtp server on your own (one hint: if you don't provide an smtp pass as an argument or as a config option you will be prompted for it).
now you have a patch that you haven't pushed yet. you can run one of the following sets of steps to get going.
git format-patch -M HEAD~1 # commitish. commit before the number of patches you want to generate
vi 0001-patch-name # and add some description between the --- and the diff stat
git send-email 0001-patch-name # can replace this step with MUA of choice
git format-patch -M HEAD~5 # generate a patchset of the last 5 patches
git send-email --annotate *patch # will open the core.editor you set in gitconfig to edit the patch
git send-email --annotate --format-patch -M --to=destination-email origin/master
# generate all the patches that aren't committed against origin/master branch in your local branch
for the time being you should probably just send it to one of your own projects on cpan so you can see. If you look at the web interface for the bug you'll notice it's clobbered your formatting, same goes with the email RT sends you... so this is useless right? well... certainly doesn't help... now look at the 'with headers' version. Their are lots of headers here, but all your content is intact. Now download this file (right click save as should do it).
you may now ( you may have to run git reset --hard HEAD^ first to undo you last commit). git apply downloaded-file.txt
which will only apply the diff no commit log or anything (reset without HEAD^ now).
or you can git am -i downloaded-file.txt -i is interactive and will allow you to choose whole folders full of mail patches and which to apply.
I think this is a good workflow for 1 off patches. obviously you don't send them to yourself, I'm just trying to show you what it's like to send and receive.
Perl 5.12 has been languishing in the testing repo for a while, there are now several packages that have been rebuilt in testing and community testing. All of the rebuilds I reported have been fixed. If you use arch please make sure you're using their rebuilt packages (and not one you rebuilt because it took like 2 months to do this) if you have any problems file a bug. If you aren't sure which package is really the problem feel free to drop me a line and I'll see if I can help you tack it down. I have over 200 cpan packages on my box right now all of which successfully pass their test suites.
Not much to say here, but if you didn't know it if you put a file.pod in your github repo it will be parsed and formatted, here's an example: Unfortunately you have to actually visit the GIST to see it rendered.
For those that don't know I currently create packages for AUR, and I used to work on Funtoo, as well as a fork of it Regen2 (which died by my hand). So I've got some experience working with BSD-ish style distro's. I can't comment on the Debians or Red Hats of the world, other than REPO HELL DRIVES ME NUTS. Now to the topic. Semver seems sane except for 1 thing that it doesn't mention and an example that encourages it.
A normal version number MUST take the form X.Y.Z where X, Y, and Z are integers. X is the major version, Y is the minor version, and Z is the patch version. Each element MUST increase numerically. For instance: 1.9.0 < 1.10.0 < 1.11.0.
Not all packaging systems are capable of dealing with multipart as actual multiple parts. Lets give a more complete example to break it down. For instance: 1.9.0 < 1.10.0 < 1.11.0 < 2.0.0. That's what's supposed to happen... but that's not how it works. Arch for example see's versions as strings... so let me show you what happens.
190
1100
1110
200
This is essentially what you could interpret the "."'s are essentially ignored ( Ok it's not actually how it works... juster's comment is more accurate than me but I think it's a good rule of thumb). They don't matter they're like spaces between words, they simply make it easier for a human to read. Never ever, ever, EVER! change the length of your versions to anything BUT larger. You will cause downstream annoyances, sure we've tools to work around it, but I don't want to and it shouldn't take any extra effort from upstream to make sure this doesn't happen.
In order to solve this if you ever need to move anything to double digits just don't go backwards. In other words: 1.9.0 < 1.10.0 < 1.11.0 < 2.00.0 would actually evaluate properly. I find it more likely that in an X.Y.Z schema that you will need X.Y.ZZ though, and maybe X.YY.ZZ. For a project More than 10 years old XX.YY.ZZ could happen. Anything more is probably ridiculous. If you find yourself hitting 99 slow your roll before you reach it by moving to a time based release, no more than once a month for example.
Some people will say that Arch doesn't have a sane internal representation. Keep in mind that maintain over 300 package now for arch... of those 300 maybe 10 have ever caused me to create a workaround because of this issue. It's not difficult, so please just be considerate of downstream, it's a lot easier to acknowledge and be mindful of this than it is to fix downstream in a way that would work for all upstream packages (e.g. we've got more to consider that just your package).
UPDATE: Read juster's comment if you want more information on actual implementation and how I'm slightly wrong.
This is a pseudo reply to Jason Calacanis for what he said about using an Open Source game engine to build a game in This Week in Startups #54, Ask Jason segment. For more shows ThisWeekIn.com.
I believe Jason is implying that you can't make money with open source software(that's not a support contract variant) directly, but it's a good resume builder. True there aren't any big billion dollar open source companies, and companies like Red Hat make money off support, but I don't believe he's correct. But there are 100 million dollar open source companies (Red Hat), and companies that make billions, and have a successful open source strategy, not all of which is support.
For starters I am not a lawyer, successful entrepreneur or venture capitalist, I am a student about to start ~ his last year of his CS bachelors. I will mostly be referring to the GPL family of open source licenses, as a generalization on open source, so if what I say doesn't match your specific OSI approved license that's why.
Piracy
Probably the biggest concern you have with open sourcing your software is that people will be able to use it for free. Guess what? almost all software worth using is available for free if you know where to look. Those that aren't are usually web only or have there distribution channel well locked (e.g. like apple store not available on cd). All this DRM-ed software out there has people distributing it and making cracks and keys available for it. So even if you built everything and locked it all up with DRM people would still find a way to not pay for it.
Licensing
Selling
Absolutely nothing in Open Source says that you can't sell your product or your source code. In fact the GPLs explicitly allow it. Not only can you sell the resulting binary and medium that it's distributed on, but you can sell the source too, you just have to make it available.
Using
All versions of the GPL allow you to modify the code for the use of the entity (business or personal) so long as you do not redistribute that code (meaning you can modify gpl to your hearts content inside of a business and not have to give anything back).
LGPL
The LGPL specifically allows you to call their API in a proprietary piece of software, and only if you modify the LGPL software itself do you have to share that code.
GPL
Mandates that you share any code that is a derived work of the GPL work under a GPL Compatible License. In the specific case of wordpress themes, what derived meansiscontested. I particularly like this:
Seem's the GPL FAQ clarifies all various circumstances in the next few sections. I certainly wouldn't want to be a python programmer... I do believes this means you can't make any python code that uses a core python library proprietary.
One way around it may be how NVidia releases their drivers when the Kernel is GPL2. They create a small wrapper module in kernel and release a binary blob outside.
Another way is if your program is served by a server, technically under the GPL this is NOT considered derived as the program runs on YOUR server, thus you don't have to share the changes. A webapp based on GPL software can be as proprietary as you want it to so long as you aren't distributing it (Not sure about the legal case on software hosted by a hosting company). It also means if it's your companies hardware, you don't have to open source it (this has been pulled on 'rented routers').
AGPL
This is the strictest of licenses, and is meant to insure open code in the event of the final paragraph of the last section. You must share code if anyone outside of your entitity is using the software.
Binaries
Nothing says you have to release the source of your games with your binaries. If your game hits the shelves of best buy and works.. most people will never bother to look see that the source is available, and that is completely legal.
There are 2 types of game(er)s... casual like Farmville, and Bejeweled... and hardcore games like Half-Life, StarCraft, Neverwinter Nights, to name a few. Casual gamers are usually not sophisticated computer users. "I should update my antivirus? what's a browser?", are not things I would be surprised to here them say. Hardcore gamers are however, and most can probably rattle of their system specs and know not only to update their AV but how to disable while gaming, many even know how to overclock their system.
Casual gamers won't be able to figure out how to assemble your source to even begin to consider pirating it. Many Hardcore gamers could, and might just to try to get more performance out of it. Most would still pay for it though, because your code doesn't include any DRM, which is becoming more annoying to them (and of course you made a great game worth buying right?).
Building software binaries isn't easy, I don't think that any license in open source requires that you include documentation on how to do so. Although you might be seen in a negative light for doing this and someone else will figure it out and publish it. This will require your users to download a toolchain of software and use it. This is not corporate IT, most of them haven't done this and it'd be too intimidating for all but the most determined (for novice software builders).
Contributers
Almost all of the Really long lived games such as Half-Life, and StarCraft had the ability to be modded, sure the source code for the engine wasn't available, but you could make your own 'mini games'. That couldn't be played with out the original. If people had the source for your game engine too they could do even more than standard modding to make your game better. Heck, they might even port your game to a new operating system where you could make money on it from the game. As your company grows you could recruit these contributors to your company.
Marketplace
Or should I say Mod Store, why not create a marketplace for gamers to sell or give away their modules. They can pay you a percentage of royalties.
MMO
Did I mention that whatever is on your servers doesn't have to be Open Source? what good is World of Warcraft without the servers? and how much is it really hindered by a free competitors on their software like The Spirit Realm. Which just to clarify is a free version of World of Warcraft built on proprietary WoW run on their own servers. I don't see Blizzard bleeding money over it, or suing.
Giving your competitor an advantage
This is the main reason that games don't open source their engines, they are afraid the competition will steal it. I don't really get that, you're a gamer, you play good games, and you play and buy more than one. Most of the time you only buy one copy so it's not like they'll make more money convincing you their product is the best. But you can charge to license your engine. What'd be wrong with that?
My conclusion is that I don't know really understand why a company that's big enough doesn't try it. EA and Activision both release enough crap to try it with one game. I honestly think you can make money on any quality Open Source software that you could make money on if it were proprietary. If you do it though, much like Red Hat, you may not be able to expect to be a leader financially, but that doesn't mean your revenue's will be anything to sniff at.
A lot of people think I'm a $explicative (insert your favorite one there). I've said some things that I shouldn't have because I was pissed at the Person(s) at the moment. I would like to formally apologize to RJBS for the negative things that I said, about him. He's been nothing but kind to me and is a great contributor to the perl community (and maybe others?). I greatly disrespected RJBS and I actually do regret it. I should have posted this weeks ago when I realized I shouldn't have said it.
I hope that RJBS will accept my apology.
I would however hope that RJBS or any other member of the perl community would not take exception to my contributions even though I can be an $explicit.
So I haven't been hacking perl for 5 (or more) years but I forked Template::ShowStartStop from Template::Timer which is that old. since I forked it this test has bugged me since I didn't really understand the test, the section of code it referred to or the actual problem.
This is an approximation of the error you'd get.
Couldn't render template "undef error - Can't call method "name" on
unblessed reference at /usr/lib/perl5/site_perl/5.8.0/Template/Timer.pm line
66. "
This error is actually a copy from bug #15457 but I happen to know it's basically the same error you'd get with an eval.
So what's the problem? can you spot it? ( original timer code )
Ugh! That's ugly, let's take a cue from Perl Best Practices and format it as a tabular ternary instead. Now we can read it...
Bug #13225 suggests a problem with eval and the following fix (which I translated into something more similar to the current code).
well that should fix our eval problem... since an eval will be a reference of type SCALAR. but what happens if it's a reference not of type ARRAY or SCALAR? then we'll still get that error.
If the referenced object has been blessed into a package, then that package name is returned instead. You can think of ref as a typeof operator.
what this means is I could check what type of object it was that I was normally getting. In order to do this I put $what into the output I get. I found out that most of the time $what is a Template::Document. So now I optimized my code for that situation.
See the thing is that we really don't want $what->name method to be called unless it's a Template::Document which actually has that method. I'm not sure that I'm not missing any tests at this point, but I'm pretty confident that, at least, this kind of bug won't crash my module anymore.
So the poorly made patch the other day converted my Test::More test to use Template::Test which removed quite a bit of code from the test itself. I hadn't seen Template::Test beforehand.
Here's a very simple example of a test you could write to make sure a template is being output ok.
So I received my first patch for Perl code a week ago. Amazingly I didn't have to tell the person patches were welcome, they must have assumed so because my project was licensed under an OSI approved license. Also amazingly I've applied the patch even though it didn't meet my quality standards. I figure that's my fault though because no where did I document what those were.
Back when I forked Regen2 from Funtoo one of the first things I did (and a reason for the fork) was create a policy for patch submission. The policy for Funtoo was that all patches were welcome, and I recall 2 patches by 1 user specifically that should have been 10 patches and 2 (or more) of those 10 patches should have been dropped, because they were doing things they shouldn't have. In order to create this policy as easily as possible, I stole Git's SubmittingPatches policy and modified it to work with Regen2.
Once again I've been faced with patches that just aren't up to par. So once again I'm using Git's policy as a baseline for contributions to my projects. Here's the beginning of the documentation
Checklist (and a short version for the impatient):
Commits:
- make commits of logical units
- check for unnecessary whitespace with "git diff --check"
before committing
- do not check in commented out code or unneeded files
- the first line of the commit message should be a short
description and should skip the full stop
- the body should provide a meaningful commit message, which:
- uses the imperative, present tense: "change",
not "changed" or "changes".
- includes motivation for the change, and contrasts
its implementation with previous behaviour
- if you want your work included in the main repository, add a
"Signed-off-by: Your Name " line to the
commit message (or just use the option "-s" when
committing) to confirm that you agree to the Developer's
Certificate of Origin
- make sure that you have tests for the bug you are fixing
- make sure that the test suite passes after your commit
Patch:
- use "git format-patch -M" to create the patch
- do not PGP sign your patch
- be careful doing cut & paste, not to corrupt whitespaces.
- provide additional information (which is unsuitable for
the commit message) between the "---" and the diffstat
- if you change, add, or remove any features or
make some other user interface change, the associated
documentation should be updated as well.
- if your name is not writable in ASCII, make sure that
you send the patch in the correct encoding.
The only part I added was to add documentation for features. Obviously some parts under patch need modification as I'm not using a mailing list.
Obviously part of the reason I don't like "Patches welcome" is I've seen that policy lead to the acceptance of really bad patches. Now obviously I make mistakes, everyone makes mistakes, but patches can be improved before they are committed. Even good patches can be flat out rejected for other reasons (I've had this happen. The consensus was not that the patch was bad, but the entire script need to be rewritten).
So what was wrong with this patch if I accepted it? well essentially it wasn't a git patch and it was applied to the wrong directory (because I had the original source in src/ and the generated a / I'm not using CommitBuild to another branch) and, it also broke my test suite (even though it was a patch for a test. The breakage was a bug in another test).
In any event, I believe that having your project be "Open Source" and having a patch submission policy does more to say "Patches Welcome" than "Patches Welcome". You don't have to agree with that, but regardless of whether you do, or not, I think having a policy is a good thing.
P.S. Trolling posts will be deleted. Be constructive or talk elsewhere.
so the whole 'open source' has no warranty thing keeps coming up as a defensible reason that I'm wrong.
Microsoft offers a 90 day limited warranty that the software will work to some degree or another as advertised or some such. If you really want to consider what they're saying... it should work if it doesn't we can send you another disk or you can return for refund. which really is what you could have done at the store anyways. I suppose it also means it won't fry your hardware, does anyone know any stable open source software that does that? I suppose a few things could if tweaked right..
Open Source generally doesn't distribute a physical medium, or fry peoples boxen, so what would we even use a warranty for? oh right... a CYA. We really don't want to be sued because someone downloaded our software and it didn't work or broke something of theirs.
Generally your software warranty doesn't really cover support, and if it does it's for a very limited time, and very limited support. Warranties are more for physical medium. For example my Dell came with a 1 year warranty, but because I ordered it with Ubuntu they would provide hardware support only.
The point is that if you're claiming we shouldn't support our software because it is without warranty... the warranty as far as I can tell doesn't have much to do with the software and everything to do with the medium.
Really, the CYA is a good thing. I don't disagree with it... however, it shouldn't be used as an excuse to do nothing. It just means you can't be legally harmed if you do nothing.
people seem to think that I'm saying support should be a #1 priority. will someone please cite where I said that? yes I said it should be a priority, I said you should do it. I did not say where on the list it should fall. Even if you're an employee at a company making $100k a year, if you're wife is dying, your priority is that, hopefully your children come before said company in most cases too. Understand, that I'm not saying put your software (paid or unpaid) before your life. That would be stupid. I'm saying get this stuff worked into your schedule for working on software. Support is part of the software lifecycle. If you have 2 hours a day to code set some of that aside for support and documentation (pooma number).
Yes, I think I've proven that volunteering to do open source comes with a responsibility or obligation. However, since there is no governing body, and no one has given us rules of good behavior. What that good behavior is, is what is subject to debate.
So hopefully we can stop arguing that we have no responsibility due to being unpaid volunteers and a license, which is really (I believe) just meant to protect us from lawyers. Once we do that we can actually discuss what it is that we actually should consider ourselves responsible for, and more importantly how we can communicate it.
Software licenses is general do not communicate these things. I think David Golden said is on the right track. Keep in mind some Open Source projects (e.g. PostgreSQL discuss a support policy outside of their licensing ) I think postgres policy is excellent for a project of its size. However, I don't expect anyone to support a single release of a small project for 5 years. 1 year might be appropriate for a Major release version.
Actually, PostgreSQL is an exemplary example of how Open Source should be conducted. I've requested stupid features and been told why they were stupid, and no one cried foul of users requesting features. I've asked for help and always received excellent support for my problems. I personally have never been able to locate more than a minute documentation bug in Postgres, and it seems that all new features are adequately documented as part of their QA.
Why is it that we don't all strive for this level of quality?
p.s. the reason postgres created that policy in the first place was that some people started thinking they were supporting old versions (like 7.4) for too long.
UPDATE: I'm locking comments. I'm tired of people commenting when they obviously haven't complete read what I've written. Either that or there grasp of English is poor. It's irritating to be constantly misquoted.
So, I'm heavily criticized for my unpopular opinion that open source volunteering is a job. I would like to point out the definitions of Volunteer and Work from answers.com I have removed a few irrelevant definitions, like those of 'botany'.
n.
A person who performs or offers to perform a service voluntarily: an information booth staffed by volunteers; hospital volunteers.
Law.
A person who renders aid, performs a service, or assumes an obligation voluntarily.
v., -teered, -teer·ing, -teers.
v.tr.
To give or offer to give voluntarily: volunteered their services; volunteer to give blood.
v.intr.
To perform or offer to perform a service of one's own free will.
To do charitable or helpful work without pay: Many retirees volunteer in community service and day care centers.
also
n. 1. a person who freely enrolls for military service rather than being conscripted, especially a member of a force formed by voluntary enrollment and distinct from the regular army.
2. a person who freely offers to take part in an enterprise or undertake a task.
3. a person who works for an organization without being paid.
v.
1. freely offer to do something: he volunteered for the job.
2. offer (help) in such a way: he volunteered his services as a driver for the convoy.
3. work for an organization without being paid.
4. commit (someone) to a particular undertaking, typically without consulting them: he was volunteered for parachute training by friends.
You'll note 'service' and 'work' mentioned. Examples include things like 'fire fighters'and 'hospital' workers and 'military personel'. Imagine if these 'volunteers' didn't feel any responsibility for the work they did. ( actually some open source people do like definition #4 here. I've been volunteered several times in this way )
n.
Physical or mental effort or activity directed toward the production or accomplishment of something.
A job; employment: looking for work.
A trade, profession, or other means of livelihood.
Something that one is doing, making, or performing, especially as an occupation or undertaking; a duty or task: begin the day's work.
An amount of such activity either done or required: a week's work.
The part of a day devoted to an occupation or undertaking: met her after work.
One's place of employment: Should I call you at home or at work?
I don't think these definitions say something other than what I have said. I believe they will be similar to what is found in other English dictionaries.
Ultimately, I do not understand why people are so vehement against this definition for open source 'volunteers'. I can't make you believe this is true, or do it. But my believing it and others believing it hurts nobody. In fact those who are helping and believe it probably produce good, perhaps better, work.
Agree, or disagree, for the most part I don't think I'm going to change anyone. It seems I've only angered good people. My thoughts on the matter aren't going to change. If people want to take their contributions more seriously, that can only be a good thing, in my humble opinion.
When I forked Regen2 from Funtoo over a year ago I created a web page for it on sites.google.com. The hosting and uptime were both right for what I needed. The dns has long expired but I went to sites today to find a public link to the content, only to find that at some point they upgraded sites and completely trashed all the content I had put on there. Sure they have a revision control on there now... but it doesn't contain ANY of the content I had left. WTF Google? I'm sure someone is going to say 'backups' but honestly, I killed the project, whatever was there wasn't really important to me anymore. But I didn't expect that it would get trashed in some Google update.
As of right now Software::License has no way to combine licenses on the fly. To be honest this deficiency might not be a bug in SL, it could be in Pod::Weaver or Dist::Zilla this is a know deficiency and RJBS plans on fixing it at some point. In the mean time we can implement dual licenses (and multi-licenses) in much the same way the Perl5 license is implemented.
I was probably in legal violation (I am not a lawyer) with Template::ShowStartStop version 0.05 and 0.06 because I used Perl_5 licensing because that's the closest I could get with Dist::Zilla, due to the limitation. So I created Software::License::GPL3andArtistic2 which is sort of a perl5 license, except that it mandates the latest version of GPL and Artistic (at the time of this writing). Version 0.07 of Template::ShowStartStop is back in compliance with the licensing of the code I forked from Template::Timer.
This hasn't, and will probably not be merged into Software::License because it's just a stopgap measure until multi-license support can be implemented.
UPDATE:
this is apparently not necessary according to Duncan and the this interview I've updated the module to reflect this. Hopefully, it can serve as an educational source.
Curious... why doesn't Perl5 switch to the Artistic 2.0 then... (I wonder what that would mean for 'under the same terms as perl5' but actually including gpl1 and artistic 1).
UPDATE: I shouldn't have said what I said about RJBS and have apologized publicly
Test Driven Development should be Test and Documentation Driven Development. I don't want to read your code to figure out how to use it. I don't really care if you write the Test, documentation, or the feature first. But you should do all three before moving on to the next one.
I'm gonna pick on Dist::Zilla this seems like a very good tool. Except it's documentation is so sub par it's not funny. The new documentation is quite good, although, I have not decided that I like the 'choose your own adventure' format. However none of the documentation on CPAN is good. It ranges from significantly less than the new tutorial, to virtually non-existant, to completely inaccurate.
You know what? It's not acceptable not to write documentation, especially not when you were apparently paid to do it and have shown that you are capable of doing it. Some people I've talked to think not documenting things is ok. I don't think it is, and it's yet another one of my unpopular opinions. Sure you can not document them... If someone else has volunteered and is actually doing it.
Yet maybe this is one of the reasons perl has fallen by the wayside. Documentation is usually either cryptic, incomplete, or inaccurate. Even the core docs like perlintro has inaccurate and potentially damaging information. Why are we so surprised that so many people don't know how to program perl in a modern way if the documentation is so bad?
Documentation should explain who, what, when, where, why and how. Who should use this module, what they should use it for, when they should (and shouldn't) use it, where they should use it, why they should use it, and how to use it. Unfortunately most documentation fails at all but the how, and the what. Who is an Abstract, and Description thing, you should consider who doesn't need it. Why why can be tightly related to who, but really I want to know why this module and not another, consider who needs a templating engine vs why it should (or shouldn't) be HTML::Zoom. When is also closely related to the previous 2 and will probably be answered with them, although consider when to use a for loop vs when to use a while. Where could be anywhere from top of file, to your view in a catalyst program. How is obviously the actual code and should be covered in the synopsis. Sometimes you'll have to think if you've answered all these, but if you manage to answer them all in a comprehensive and complete manner then you're documentation is probably good enough to be useful.
I don't expect people to be perfect in this, but some effort is better than none. Also if you write documentation, you may end up answering less questions, and save people many hours finagling a problem.
I'm sure even my modules fail to meet my own standards.
The best documentation I've seen is PostgreSQL's and Gentoo's.
Don't say "patches welcome" it does more harm to your community than good. Why? It's a polite way of saying "I don't care. Fuck you. Fix it yourself. End of discussion".
1.) Not a Developer
The person you are saying this to is not developer. They don't know how to do it. PERIOD. At this point you are refusing to help them. This person may now have the opinion that your community isn't helpful. Don't ever for any reason assume someone is a developer, assume they are not. I would wager only 1 person in 10,000 is a developer.
I was once told that I should be able to fix a bug in git (msysgit technically) because git is a developer tool. At that time I couldn't code at all but was using git to store homework or something...
2.) Novice Developer
Some how you know the person can code through some method other than assumption. They aren't as smart as you are, there code is so amateurish that it wouldn't be worthy of inclusion, even if they could figure out how to fix the problem. They can't get that far, they've no idea where to begin. You're probably just frustrating them instead of helping the problem. All people that you know are developers fall into this category (unless they fall into the next), either be willing to help this person patch your code or just give them the real reason (e.g. I've no interest in this problem) for not helping. These people know they could be helping, they may even want to be helping, but you telling them that they could be is not helping. They need guidance, not an invitation.
3.) Doesn't Care
So the person doesn't fall into any of the 2 above categories. Guess what? they don't care about it enough. They don't need you to tell them "patches welcome", they know what open source is. They know they could send you a patch, and that you might accept it. They know all that, but there's some reason they don't want to. You aren't telling them anything they don't know. Again just tell them the truth of why you don't want to work on it. Maybe ask them why they don't. Maybe it's a silly little barrier that you can help with. But only bring that up if you know they are competent enough to do it.
Just Stop
Just stop, after years of hearing this when I couldn't do it. All I hear is "fuck you I don't want to take the time to help you". Why would I want to help if that's what I hear? Don't tell me it's not what you mean. Because I've had that said directly.
Stop acting as though everyone can or should write you a patch. Most of you don't agree that you have a responsibility to the free software you create. No one else has a responsibility to contribute to the software. They aren't leeching if they don't give back, you gave it away. Don't ask them to, don't tell them to. They don't want to hear it anymore than you want to fix their problem. Definitely do NOT "volunteer them" to get something done, that's just plain rude.
Pretty much everyone you've ever told this too already knew that patches were welcome, so there's some other reason they weren't writing one.
Exception: If someone asks you if you mind if they work on your code. You can of course answer them "patches welcome" this is because they asked, as opposed to you volunteering that info.
So lastweek you should have covered variables, conditionals, flow control statements, calling functions, stdin/out/err, and using new perl features.
This week we're covering text processing, scalars, external libraries, and reinforcing what we learned last week. Text Processing is one of Perl's specialty's, mostly due to it's powerful regular expression engine.
First install LWP with cpan. cpanp -i Bundle::LWP will do it.
So this is almost completely new... what does it do? and what does it have to do with text?
LWP is short for lib www perl. LWP::Simple is a simple procedural interface to it. getprint is a method which is roughly equivilant to fetch uri and print the content that you got back. So this isn't very useful... (ok it's actually quite useful if you're on arch and you want a PKGBUILD) what we want to do in this case is cut the junk and print the pkgname. As a side note, this code does the exact same thing as the python example in Head First Programming: A Learner's Guide to Programming Using the Python Language but is shorter if you cut the boilerplate (#! ... use strict; use warnings ), and the same length if you don't.
Now let's have a first attempt at getting the package name shall we? We need to read the contents into a variable first. note: we've changed from getprint just to get because it returns the contents to a variable. (note: still shorter than the python.) At this point the book goes into how a string is an array of characters. Perl is contextual so at this point our scalar is essentially a string but just because it's a scalar does not mean it's currently a string. In our previous examples we were handling it in a numeric context.
So here we're looking at the 11 character substring past character 281. The output should be modern-perl. This code is horrible, what should happen if I were to change this PKGBUILD? (if this ever doesn't output modern-perl that's probably exactly what happened). Remember say appends a newline character to it's output print doesn't. We used print previously because the output already had a newline at the end.
There are thousands of PKGBUILD's on AUR let's see if we can get the name from another one by changing the URI.The output at the time of this writing is
dirs')
depe
and will probably change. A newline is just another character in the scalar so nothing prevents one from being printed within the substring. Our URI got a little long here so we moved split that peace of code up to be on 2 lines for readability. Your code lines shouldn't go over 78 characters long if you can help it. A URI would be an acceptable exception though.
So we use the index function to search the string for some text and return the position we can then use that position to get our substring. The position returned is 1 less than where the string we searched for starts. So we added the 9 to get to the string we actually want. Our output is now
perl-moose'
why the '? well "perl-moose" is shorter than "modern-perl" so we've got extra characters in there.
Let's use a regular expression.
regular expressions are really their own mini language, very terse, and several dialects. Have your students go through the Regular Expression Tutorial and the Regular Expression page. In short this regex looks for pkgname='something' in $content and takes something and puts in in $pkgname. the ( ) in the / / tell which part of the regex to assign to $pkgname. [\w-]+ says to match 1 or more alphanumeric or _ or - characters. Regular expressions is a huge topic in and of itself. So don't spend a huge amount of time on it, they are important to know, but you don't have to master them right now.
The example in Head First Programming: A Learner's Guide to Programming Using the Python Language goes on to explain how to check the page periodically for updates, and only output when a value is less than a certain amount. Since I have no idea when I'll be updating these PKGBUILDs I don't want to get into that code. It would make a good homework assignment. You can use sleep to make sure you only fetch the code ever so often. I can guarantee barring a buggy release I won't update any PKGBUILD more than once every 86400 seconds (1 day). You'll have to check pkgver and pkgrel to see if either of them are newer than the previously fetched PKGBUILD.
So I think that Head First Programming: A Learner's Guide to Programming Using the Python Language is a great guideline to teach any programming course, esp a 10 week course as it has 10 chapters. We're one week behind. Arguably you could merge week 2 into week 1 and I may do just that in a rewrite of this series. In fact I'd suggest you do just that. But for now I'm going to continue on and we'll see what people think once I reach the end. No reason I can't rewrite this series, especially since it's not really planned I'm just writing it on the fly.
Although this book is a good guideline (note: I'm also concerned that if I follow it's examples to the letter all the time I might violate fair use), chapter 2 annoys me, it's on textual data and uses html scraping as an example. However, it completely ignores html parsers and any other sane way of doing it. So I had to find a better example and I think I have with parsing PKGBUILD's, which are sort of a microformat bash script.
and decided I wanted to go back and play with Catalyst and REST some.
page 140 will save you here (actual quote pg 475 a summary chapter). 
but is shorter if you cut the boilerplate (#! ... use strict; use warnings ), and the same length if you don't.
and possibly 
and if you want some common recipes 
. You should also warn your students that although you can use regular expressions to match any kind of text, that in the case of well defined formats, such as xml, html, csv, ini and more that there are better ways of extracting data. In the cases of things like email and phone numbers they should not write their own regex's but use modules to validate such things as they will undoubtedly make mistakes doing so, and a module has been well tested.