Programming Leftovers

posted by Roy Schestowitz on Sep 04, 2022

• Welcome to Pitivi GSoC Update 4

  Hey everyone, hope you are doing fine. This is my fourth update related to Pitivi GSoC, and this time I got a bit late at publishing, more details later on in this blog, so keep reading :)

• The Commoditization of Large Language Models: Part 2

  Since I wrote Commoditization of Large Language Models almost two months ago, things have progressed much faster. There are now two serious competitors to DALL-E: Midjourney and Stable Diffusion. DALL-E pricing hasn't changed, but GPT-3 is now cheaper.

  [...]

  The cost moat is nearly gone – new models are trained cheaper, on non-proprietary data, on commodity hardware. Access to these models is trending open rather than closed.

• Things tech recruiters look for in your resume and first interview part 3

  Have you applied to 10s of tech jobs and never heard back from anyone? Are you sure that your resume does its main job of getting that first call from the recruiter? Do you want to know what tech recruiters look for in the initial call? If any of your answers were yes, you must read this post.

  In this piece, you will hear from three amazing tech recruiters from Sydney’s popular companies reveal the secrets behind a great resume and acing that initial call with the recruiter. Stay tuned!

• Robust Poisson regression in medical biostatistics

  Log-binomial and robust (modified) Poisson regression are common approaches to estimating risk ratios in medical biostatistics [1].

  I have discussed log-binomial regression in a previous post about generalised linear models. The conceptual basis for using log-binomial regression to estimate risk ratios is straightforward – it is natural to specify a binomial (Bernoulli) distribution for a binary outcome, and a log link puts the parameter estimates on the risk ratio scale.

  Robust Poisson regression, on the other hand, seems harder to justify. Under the usual parametric view of generalised linear models, it seems to assume a Poisson distribution for a binary outcome, which is incorrect, as a Poisson-distributed variable can take any non-negative integer value, but the outcome can only either happen or not.

• Data Science Challenges in R Programming Language | R-bloggers

  Data Science Challenges in R Programming Language, Take-home challenges in data science will force you to step outside of your comfort zone.

  But guess what?

  That’s advantageous because it’s the one area where you’ll actually learn stuff. Both novice and expert R programmers must learn to master the take-home problems, but the challenges you’ll tackle will differ greatly depending on your degree of expertise.

• Training and Testing Data in Machine Learning | R-bloggers

  If you are interested to learn more about data science, you can find more articles here finnstats.

  Training and Testing Data in Machine Learning, The quality of the outcomes depend on the data you use when developing a predictive model.

  Your model won’t be able to produce meaningful predictions and will point you on the wrong path if you are using insufficient or incorrect data.

• What are the algorithms used in machine learning? | R-bloggers

  If you are interested to learn more about data science, you can find more articles here finnstats.

  What are the algorithms used in machine learning?, In less than a minute, this article will explain some of the most popular machine learning algorithms, making them easier to understand for everyone.

• Laurence Tratt: A Week of Bug Reporting

  If you use software regularly, and have your wits about you, you will often realise that you've encountered a bug — in other words, that the software has done (or not) something that it shouldn't (or should have). When this happens, the vast majority of people moan to the nearest bystander about how incompetent the people behind the software are and then carry on with whatever they were doing — often stumbling into the same bug repeatedly. Only a minority of people think of reporting bugs and, if they do think of it, they often fail to do so either because they think it's too time-consuming or that they might end up looking silly.

  It's unfortunate that so few people report bugs. First, surprisingly few bugs affect a single person: by the time someone does report a bug, it can have affected hundreds or thousands of other people. We can't all be freeloaders — someone has to take the plunge and report the bug. Second, bugs frequently appear in contexts unfamiliar to the software's developers [1]. Most obviously, we all have slightly different software installations, and those variations can cause odd effects. Less obviously, users often use software in ways unimagined by its creators, such that some previously untested combinations of operations work incorrectly [2]. Either way, we cannot assume that the software's developers will encounter the same bugs that we do: in many cases, if we don't report bugs, the developers simply won't know they exist.

• Giving Names to Things • Buttondown

  First of all, new post: Software Mimicry! It’s about a thing I’ve seen in a lot of software tools and products that I was trying to capture in a single term, so I could share it and explore what it actually means for things. It’s also a rewrite and expansion of one of my very first newsletters: on emulation. I find myself fascinating with terms. Mimicry is something I see in a lot of different places, and I’ve seen people identify particular instances of it, but not connect the dots and discuss the abstract concept of mimicry. Is “articulating” mimicry into a distinct term useful? I think so! By having a term for something you can discuss it as a thing instead of being forced to gesture vaguely at it through examples.

  Take, for example, “side effect”. A side effect is when a function changes the outside world in addition to computing a value. Changing a global value is a side effect. Allocating or freeing memory is a side effect. Updating the cache, advancing the RNG, and making a POST request are all side effects. Side effects are generally something that increases software complexity, so are often implicitly avoided, or explicitly embedded in software constructs like monads and algebraic effects.

• Measuring demand for a feature: An economics approach

  How bad do users want a feature in your software?

  What if we could use good ole economics to answer the question? The supply of new features you can provide in your software is limited, so measuring the demand accurately is vital.

  Let's think about how we could measure the demand for a feature...

  We could ask users what they want. Interview or survey them. Take a poll and give them a few options. Or scrape forums and social media to see what they're already asking for. Maybe even show them a mockup and get their feedback. Do they say they can't live without it? These are all standard methods in a user researcher's toolbox.

  The economics term for this is stated preference, what someone says they want. The problem is that stated preference often does not align with revealed preference, that is, what someone's actions reveal to be their preference. To put simply, just because a user says they want a feature doesn't mean they will actually use it. I've even written about my own experience where these did not align: When users never use the features they asked for.

• Free Python Tutorial For Beginners: Learn Python - Python Land

  Are you looking to learn Python? Look no further. This free Python tutorial contains 100+ carefully crafted, free Python articles full of information, practical advice, and Python practice! We’ll dive into the basics and work our way up to advanced concepts. I’ll provide you with many examples to explain all the concepts clearly.

• openSUSE in 2022 | Continues to be Awesome - CubicleNate’s Techpad

  I have been pretty quiet here on CubicleNate.com for a few months, not because of any lack of interest in what I do but rather that there have been life things that have gotten in the way. I have many incomplete blatherings that are waiting for me to finish writing them up. The one thing I can say with absolute certainty is my passion for openSUSE hasn’t gone anywhere. I have been, in fact, continually and increasingly happy with what has been coming out of the project.

• “OpenBSD Mastery: Filesystems” Status Report

  Why have I spent months on five chapters? Because everything in the core storage system of any Unix is intertwined to a nearly unholy degree. To understand filesystems you must understand partitioning, but to understand why Unix uses partitions as it does you need to understand filesystems. I have to meticulously disentangle facts so that I can start explanations at the bottom of the storage stack, but add in enough higher-level details exactly when you need them so you can make sense of why the bottom layers work as they do.

  Otherwise, you’d look at computers and think “Wow, this whole thing is stupid.” Don’t get me wrong, the whole thing IS stupid, but it’s your job to understand the stupidity and I don’t need to be rubbing your nose in it.