• 0 Posts
  • 197 Comments
Joined 2 years ago
cake
Cake day: August 1st, 2023

help-circle

  • You can manage an install-less solution with a docker container assuming you can get docker on the client machines.

    There are numerous PDF cli tools that will split pages for you, so the challenge is finding the right one that is trivial for you to use with docker.

    My internet sleuthing revealed that there is already a ready-made docker image for an older version of Apache PDFbox, but there are likely other docker containers you could use.

    You can incorporate usage into the above snippet pretty easily if you ask one of the AI chatbots. Your prompt will be something like: “Given this one-liner in Powershell (copypaste the one-liner), I want you to change it to also use this docker container (link to github) of Apache PDFBox 2.0 (link to PDFBox docs) to split PDFs into pages. Rewrite the one-liner to do this.”




  • Matt started young. Only a few years before I started in earnest. We were all kids in our 20s when I got to know Matt. I think everyone I knew back in the day must be at least 40 at this point. Before the community evaporated and the world moved on, a lot of cool shit was built in Perl and our community was pretty welcoming. Even to 18-25-somethings with more technical skill than sense. Such a wild time to look back on. So now you can say “how can there be at least two JAPHs younger than me” 😉


  • Matt was complicated. He had high standards for his craft and was very abrasive if he felt you didn’t live up to them. Multiple instances he rubbed people the wrong way and would sincerely apologize. He wasn’t malicious, just had no filter. The world is not better with his absence. Dude was brilliant and it is a damn shame he died so young.

    This article though, is pretty lame. Author half hears about some Perl developer dying and writes an article about how he would have vibed with him. Would it have hurt to actually to have done some research for an obit? You didn’t need to use my friend’s death as an excuse for an article just because you had a deadline.



  • Depends on the people. Eternal September has been a meme for over 30 years at this point. It is a cyclical pattern in just about anything social: experimentalists/creatives create new thing, early adopters join which gives new thing legitimacy, social contracts are implicitly drafted because the community is small and easy to reach consensus, then it gets exposure, masses of new people join the thing that aren’t interested in the social contract, community cohesion eventually evaporates. This is how you go from “Man, our thing is so cool” to “Fucking newbies spamming in general, begging.” You don’t want to share your cool thing with a bunch of mouth breathers that aren’t capable of appreciating what makes the thing actually cool. Eventually the grifters come, and then it is game over. So the original community members scatter to the winds. Some creative people make some new thing and it starts all over again.


  • Not GP, but reading gnarly code and making definitive statements about who/what/when/where/why such that your documentation is accurate, especially in a corpo context where there are not clear boundaries of responsibility, requires quite a bit of brain power. Not to mention the ever increasing entropy in systems driven by profit means that whatever you write in terms of documentation will have a pretty short shelf-life. The code might stick around as an unholy amalgamation of copypasta after a refactor or two.



  • I’d carefully consider using email for this. If you’re hosting the service, you might need to use one of the bigger email providers that already have reputation (unless you already have good IPs with good rep). Otherwise, you risk the emails sitting in spam and people’s switches being flipped. If it is self-hosted, you’ll probably need to explain the risks to users.

    Given today’s world of pocket computers, you might consider using push notifications of some kind. Or have a companion client that pokes an API and there is some kind of challenge/response.


  • Are your users technical? If not, crontab syntax is definitely to be avoided. Instead, I’d offer some simple options like daily, weekly, monthly, etc. Then convert that syntax into crontab syntax.

    I glanced at the repo, but there is no content in the README.md to get a sense of what your project is actually doing.

    For processing cron, you should consider just using cron. You can setup a user specific to the process, use that user’s crontab, and manage the entries. If the source of truth will be from the database, then you don’t even need to read the crontab itself, only (over)write it on demand.








  • Like they’ll test me on frameworks or ask me some very archaic questions which is just so frustrating to get through like I haven’t had that much experience that they’re demanding from me even in entry level positions it’s been like that.

    Unfortunately, there is probably someone in the same boat as you but has a passion for the field and is able to answer all of their tricky questions. Be the best at what you do. Did you immediately go home after these interviews and study everything they asked that you didn’t know? As an early career technologist, you’ll need to put in a lot of hours studying and applying knowledge. You’re at a disadvantage because you need to prove to them that you will add value to their organization. A CS degree isn’t enough. I’ve interviewed and rejected plenty of MS degree holders too. What matters is demonstrated ability. If you’ve not setup a portfolio of personal projects, or contributions to FOSS, you need to do that. And I’m not talking about vibe coded slop, but your own blood, sweat, and tears. That will demonstrate practical skill. Getting involved in a FOSS community can make a big difference in increasing your network and getting you exposed to others that might be looking for hands. Plus, it is cool and you’ll meet really smart peeps. If you really want to be RIF proof, you need to be really good and have a very good network of people that would love to work with you.

    TL;DR: git gud