JBrowse is a genome viewer written in javascript, html, allow with the usual Bio::Graphics modules. It can be run in the catalyst framework.
This assumes you have Catalyst, Catalyst dependencies, JBrowse, and JBrowse dependencies (mostly perl/bioperl/bio::graphics things) installed.
Get rid of your old distributions on CPAN! A couple of years ago, I asked CPAN authors to visit their delete files PAUSE page to "increase their Schwartz". Sadly, the use.Perl page has disappeared; the Schwartz Factor is the ratio of latest distros to the total size of CPAN. I named it after Randal Schwartz, who invented MiniCPAN.
Wendy noted that deleting distros was a topic at the recent Lancaster QA workshop. She didn't say much, but it sure sounded like people were looking to create policies and work to police something.
CPAN has never been curated, and that's by design. Let's keep it that way so the rules committees leave it alone. :)
Hi All
Here's an image displaying various options re SQL joins.
Wish I'd see this years, nay, decades, ago.
First of all, I have written my recent hacktivity log over on my new dreamwidth.org blog, and I am not posting it here, because it involves a lot of non-code hacktivity, which I expect to do quite a lot more of from now.
That put aside, I am copying here something that I wrote in a Slashdot comment about why I am looking for a job not in IT. Especially of note there are my frustrations with employers being too domineering and control-freaks, and not letting the good developers do things the way they most prefer to do it. Here goes:
The QA Hackathon 2013 in Lancaster went today into its last day. Still busy, bustling with energy, concentration, typing.
First thing to do was bring somebody back to the hotel because he forgot a bag, and bring him back to the university. Ah well, nice car trip.
This morning I finished up the other pages of the meeting of yesterday. I was just 2 minutes away from finishing when the next meeting started, about Testing. A lot of Testing. I filled 12 pages with notes about Testing. And after that I had lunch while transcribing those 12 pages. I handed the written notes to David Golden and emailed them to him too.
Topics today were "Automated testing vs non-automated testing" (which involved using some environment variables of which I think they should have existed years ago) and "Installing tests" (but what the real topic of that last one was, I still do not understand, I hope I will read it when David makes a report of it).
Notes from a Newbie document the creation and deployment of yardbirdfanclub.org with Perl Catalyst on shared hosting. They are intended for a Perl Catalyst Newbie who would like to study the creation and deployment of a simple Perl Catalyst application.
INTRODUCTION
Although the bitcoin protocol itself is fairly robust, our dependence on centrally managed bitcoin exchanges for price discovery creates a single point of failure for the system as a whole.
What is needed is an honest price discovery mechanism that is both decentralized and resistant to DDoS, HFT and other forms of price manipulation.
A DISTRIBUTED EXCHANGE NETWORK
What I have in mind is a distributed network of independent, yet loosely cooperating bitcoin exchanges that all communicate via some well defined protocol. The network as a whole should be very resistant to attack, since if one exchange goes down the rest of the network picks up the slack. The concept is similar to how the Internet itself works.
HOW IT WORKS
Individual traders broadcast orders (bids + asks) to the entire exchange network (or some portion thereof), thus creating a race condition among exchanges to fill orders faster than the competition. The exchange with the fastest matching engine wins the race and collect a small transaction fee.
Just in case you are bored, I've created a new, experimental screencast for Perl.
The first episode is about OOP with Moo.
Saturday 13 april 2013
The QA Hackathon is thundering further like a heavily loaded roadtrain. We are now with over 40 people (I have been at workshops with less people attending, and most of what they did was just sitting and listening). hard work being done.
Well, not all. This morning after the welcome words, we got out with a group of 10 people in 2 cars and went on a small tour to Lake Windermere and some other lakes in the Lake District. Saw some amazingly beautiful sights... panoramas... buildings... villages... It took us 4 hours but it was worth it.
The 2nd Annual DC-Baltimore Perl Workshop is almost upon us! In case you haven't heard about it, we'll be having the Workshop in Baltimore this Saturday April 20, and have extra trainings on Sunday April 21.
We have room for more attendees -- even day-of registration is ok, in case you wake up Saturday morning and think to yourself "hey! I could be hanging out with awesome perl nerds right now! WHAT AM I THINKING?! Also where did I leave my hat?"
We have a great schedule of talks this year. There will be two talks at a time -- one targeting general perl developer interests, and the other focused on training/tutorial material. Talk topics include Code Coverage, Unicode, Elastic Search, and even some Scala. [Note: We actually have a small gap in my schedule for tutorials -- if there is something you want to give a 50-minute tutorial on let me know! We have some fallbacks that I'll get in place soon otherwise].
Not before time, I have finally released the underlying files that run the main QA Hackathon website. If you want to have a play, please go to the following GitHub repo: https://github.com/barbie/qa-hackathon-website.
Each year I try and update details in a timely fashion for the forthcoming QA Hackathon and often fail. BooK requested that I put the site files online, so that anyone can help to keep the site updated. I may not have the time to write the content, but it's not too bad to accept pull requests and update the site, so feel free to contribute.
Two areas in particular I would love to see content added is firstly with translations into non-English languages, and secondly to extend the content, particularly with writeups and links about previous QA Hackathons. I will have a look at structuring some of the previous content to make it a little easier to contribute both translations and new content, but please don't let this stop of contributing if you have something to add.
More updates from the 2013 QA Hackathon here in Lancaster soon :)
Today we have released a new feature of PrePAN, developed at Perl QA Hackathon 2013 Tokyo Satellite. You can now receive email notifications when comments are posted onto your modules or discussions you're joining, which enable you to catch up with what's going on about modules on PrePAN.
This feature is available only for uses who have been logged into PrePAN via GitHub. If you have at least 1 email available via API of GitHub, you'll see the setting page like below:
You can avoid receiving email notifications by turning off the check box on the setting page.
How to notify site activities to users had been a big concern for us. It was now partly solved, we think. We're continuously working on PrePAN to make it better place.
Enjoy!
Friday 12 april
Perl QA Hackathon 2013 ( https://perltoolchainsummit.org/qa2013/ ) started this morning in Lancaster. Some 35-38 people present. Started with a warm welcome by Mark Keating and a one-minute stand-up of all participants (including me...).
Impressive number of goals by the way... this is going to mean business. Perl is going to be improved significantly, even if only one quarter of these goals are done. https://perltoolchainsummit.org/qa2013/wiki?node=Hackathon-Targets
12:18 Just had a meeting with 6 superintelligent database specialists who want to add some important changes to the way Perl handles databases and programming code that prepares to do stuff with databases. They used many words I never heard before (and some of them don't exist yet, they made them up, and didn't tell me about that).
It seems to be more important that some notes were taken than that all that was said was included. OK, I can do that. Still a bit confused. Waaaay over my head.
The Perl QA Hackathon 2013 started yesterday in Lancaster. About 30 people hacking to fix bugs in the Perl toolchain and all our tools we use daily to publish stuff on the CPAN. Thanks to all our sponsors that make this event possible and to all the benevolent hackers that came from all over the world.
Follow our news on the Twitter feed: @perlqah.
Some of you already know that I like optimizing things (modules, applications), regarding speed and scalability. For optimizing, you typically benchmark and profile. Regarding web applications, what I find very helpful also is observing request duration over time.
I've been doing this for quite a while now, and I found out, that this is not very common, so I would like to give an example and explain why it can be helpful. I'm also interested in other examples and typical values. (The only post about something like this I found was https://blogs.perl.org/users/mo/2011/07/exciting-updates-to-metacpan.html)
I worked on a new perl11 vm, p2, in the last months. In some perl11 meetings we identified several problems with the current architecture, and came to similar results as the parrot discussions a decade before.
Not only is the VM (the bytecode interpreter) horribly designed as previously observed by Gregg & Ertl 2003, also the parser is an untangable and not maintainable beast. And since any future VM should be able to parse and run perl5 and perl6 together, that's why we reserved use v6; and use v5;
Any new perl vm such as parrot, nqp with the jvm or other backends, niecza or p2 need to be able to parse both. perl6 cannot afford to leave perl5 aside, even if it's a much nicer language. That's why parrot came up first with the PGE based parser framework, which made it super easy for other language to target parrot in the first years.
Previous reports: 2012 year-end, Apr-Jul 2012, ...
Data::Sah. All through January I mostly worked on Data::Sah. In the second week of February, I completed what I call the first stage: some core set of clauses which I use regularly and a working Perl and JavaScript compiler. I can already compile most of the schemas which I use in my programs. It's been deployed in several productions already, e.g. an API service for a license server and report email processing system. There are obviously many things missing, the usual 10% hard part. But I haven't seen the need for another rewrite so far, which means the current implementation (the second, or third IIRC) is not so hackish after all.
Fair warning: if you're someone who has the shining light of the converted in your eyes and you've discovered the One True Way of writing software, you might feel a bit challenged by this post.
Your newest developer just pushed some code, but it has a bug. They screwed up the CSS and one of the links is a bright, glaring red instead of the muted blue that your company requires. While you're sitting with her, counseling her on the importance of testing, you get a call from marketing congratulating you on the last release. Sales have jumped 50%.
You know that the only change is the link color.
Was that code really a bug? Are you honestly going to roll it back?
More importantly, and this is the question that many people get wrong: what are you going to learn from this?
Last night, I went shopping for a service to monitor servers and API performance. So I looked at New Relic, AppDynamics, and a few others. From what I saw, none of them supported Perl.
That seems like a golden opportunity to me. Those companies are making some serious money (New Relic is likely to do an IPO this year). I think an enterprising Perl developer could get a piece of that pie.
If you put together the right hooks to support one of their monitoring agents from Perl, I am certain those companies would be happy to license you work from you. Or at least offer you a good job.
Individually, those companies may not feel the Perl market is worth the effort, or perhaps they just can't find the expertise to support Perl (good Perl devs are not easy to find). But if you find a way to leverage code across all those companies, then I think you would be sitting pretty.
At the Bank we have a home-grown ETL framework that we've been using for quite some time. We recently completed a total rewrite, but unfortunately we left out a few changes. Had I gotten those changes in 5 months ago, I would have only had to break the API of about 10 modules. Today, in order to make those changes, I have to break the API of 122 modules.
What follows is an account of this ordeal, provided for entertainment value only. There will be a future post that explains some of the things I did to make this task surmountable.
blogs.perl.org is a common blogging platform for the Perl community. Written in Perl with a graphic design donated by Six Apart, Ltd.
