Spoiler Alert: This weekly challenge deadline is due in a few days from now (on November 21, 2021 at 24:00). This blog post offers some solutions to this challenge, please don’t read on if you intend to complete the challenge on your own.
Task 1: JostSort
You are given a list of numbers.
Write a script to implement JortSort. It should return true/false depending if the given list of numbers are already sorted.
Example 1:
Input: @n = (1,2,3,4,5)
Output: 1
Since the array is sorted, it prints 1.
This is a quick reminder that the quarterly San Diego Perl Mongers meeting will be occurring on Tuesday evening, starting at our normal time of 7 PM PDT. As has been for the last several meetings, we’re going to meet online, as in-person meetings are discouraged, and online meetings seem to be a bit more popular.
Tau Station, "the free-to-play narrative sci-fi
MMORPG (TM)", has a nicely complex database. Currently, we have 190 tables with
740 relationships between those tables. DBIx::Class does an amazing job at
managing that complexity, since each relationship is simply an accessor on the
DBIx::Class::Row object.
However, there is a subtle issue when using those relationship accessors. Using
a relationship accessor creates a new Row object and stores it in the calling
object. This behavior can easily leads to duplicate DBIC Row objects for a
single database row. At best, the duplicates cause wasted resources duplicating
the Rows. At worst, they cause update anomalies, since updates done to one Row
object are not seen by the duplicate objects.
With a highly-connected schema like we have in Tau Station, trying to handle the
object duplication can pretty soon feel like we're trying to handle
rabbits in Australia.
In order to avoid this Row duplication, we have developed a cache of DBIC Row
objects that is shared within the application. In most cases, this allows us
to ensure that we have one DBIC Row object per database row while processing
an HTTP request, avoiding those subtle update anomalies.
Spoiler Alert: This weekly challenge deadline is due in a few days from now (on November 14, 2021 at 24:00). This blog post offers some solutions to this challenge, please don’t read on if you intend to complete the challenge on your own.
Task 1: Workdays
*You are given a year, $year in 4-digits form.
Write a script to calculate the total number of workdays in the given year.
For the task, we consider, Monday - Friday as workdays.
Several months ago I read a tutorial on module creation. It got me thinking about releasing some of my modules. I got to work getting my code organized. At the time I had all of my work in the directory for my site. So I moved my general purpose modules to their own directory and then started reading more about what is needed to get a module published on CPAN.
I first installed Module::Starter. It seemed like a good place to start, but then Dist::Zilla was suggested, so I installed it. Most recently Minilla suggested, and now it is installed. The problem is, I do not know which one to use. Do I use any of those at all, or is there yet another packaging module (with executable) out there?
If you haven't heard, Hacktoberfest has now become opt-in, to reduce the number of spammy, or pointless, pull requests that people were doing, to get the t-shirt.
In this post I'll describe how to opt your repos in, how to find opted-in repos, and why your repo might not be turning up in searches.
So if you've got repos with issues that you'd be happy to receive pull requests on,
add the topic hacktoberfest, and make sure that your repo turns up in searches.
Spoiler Alert: This weekly challenge deadline is due in a few days from now (on November 7, 2021 at 24:00). This blog post offers some solutions to this challenge, please don’t read on if you intend to complete the challenge on your own.
Task 1: Long Year
Write a script to find all the years between 1900 and 2100 which is a Long Year.
Not words you want to hear late at night before you're going to bed: "we accidentally launched our Kickstarter."
That's right, the Tau Station MMORPG Kickstarter is live and we didn't mean to. However, apparently Kickstarter doesn't allow you to "unlaunch" a campaign.
It may not have been our launch window, but we're owning this.
Share this!
Tau Station is the world's first Biblio-RPG. It's a massive, immersive, narrative sci-fi MMO. Missions in most games are things like "kill five rabid dogs and get a dagger." BORING. Our missions are rich, immersive, short stories where you control the outcome.
It's 400,000 plus lines of Perl, with a PostgreSQL backend.
Spoiler Alert: This weekly challenge deadline is due in a few days from now (on October 17, 2021 at 23:59). This blog post offers some solutions to this challenge, please don’t read on if you intend to complete the challenge on your own.
Task 1: Pandigital Numbers
Write a script to generate first 5 Pandigital Numbers in base 10.*
In my last post, a meta issue for modules: bug tracking, I had noticed a problem with the bug tracking link for a module and discussed that problem. In the comments, one person said he preferred rt.cpan.org. I began thinking about where to have bugs tracked for my modules. Since I have not published one yet, this is something I would like to know. I would like to know the good and bad and ugly of the various systems to make a more educated choice on issue tracking before my first release.
Are there specific issues with GitHub's, GitLab's, or other issue tracking systems making rt.cpan.org the more attractive choice?
On a side note, I prefer reporting issues on sites like GitHub and GitLab since my reply email is hidden and does not get spammed, or at least not yet. However, my cpan.org email address gets a lot of spam, so much spam I had to make a rule to send all email I receive through that address to junk mail. So, should I receive a reply to an issue I opened on rt.cpan, I may miss it since it ends up in my junk mail, which I do not check that often.
Hacktoberfest event is back with a bang. I have to be honest, this time I am not as excited as I used to be.
Reason?
Well, ever since I decided to go slow on submitting Pull Request, I find it hard to find anything simple and easy to work with. Another reason, I don't spend much time review latest upload on CPAN. Earlier, I would constantly watch every upload on CPAN and find anything needed helping hand.
Most of my spare time these days dedicated to "The Weekly Challenge", I rarely find time to review any CPAN module. Having said, I still manage to submit just few to keep the continuity. I struggle to even get 2-digits number each month. Last month, I could only submit 6 Pull Request, at least it is better than August.
Spoiler Alert: This weekly challenge deadline is due in a few days from now (on October 10, 2021 at 23:59). This blog post offers some solutions to this challenge, please don’t read on if you intend to complete the challenge on your own.
Task 1: Integer Square Root
You are given a positive integer $N.
Write a script to calculate the integer square root of the given number.
I was reading a module on meta::cpan when I spied a small issue. I went up to the Issues link, clicked, and was sent to rt.cpan. I know that many module authors now have their modules on sites like GitHub, GitLab, or Bitbucket. Before I posted the issue on rt.cpan, I checked the author's profile for a linked account to one of the other sites. I found the module on GitHub and read the CONTRIBUTING.md to find the author does want issues reported there and not rt.cpan. I did not report my original issue, I reported the link issue instead as it seemed more important.
Today is not the first time I noticed this issue with a module's bug tracking.
Before continuing, I have not released a module to CPAN and am still learning all that goes into releasing one. Please be gentle if I am wrong or stating an obvious well known fact.
Gisle Aas (GAAS on CPAN) is a well-known CPAN author, who made his first releases back in 1995. Over the years he has developed and maintained a number of keystone modules that most of us have relied on, whether we realised it or not. Gisle has informed the PAUSE admins that he will no longer be maintaining his CPAN distributions, and is open to responsible adoption. In this blog post we'll summarise what distributions are available, and our interpretation of responsible adoption.
If you're interested, please read this post, and if you still would like to adopt a distribution, contact the PAUSE admins (modules at perl dot org) and not Gisle.
