Showing posts with label database. Show all posts
Showing posts with label database. Show all posts

Wednesday, 3 September 2025

Replit Goes Rogue

Here's a story that will chill the beejezuz out of any aspiring Vibe Coder.

Replit is a tech company which produces autonomous AI agents. You generally create and train a tool on the company's platform using various input data, then refine its capabilities over time. Yes, I know, they're dime a dozen these days.


One Jason Lemkin, a software engineer, founder of SaaStr, a SaaS Community, reported his organization's disastrous encounter with Replit's A.I coding tool on X. Lemkin was attempting a Vibe Coding experiment to see how far he could take Replit's autonomous agent for software development, from the viewpoint of a layperson. This was innocuous enough. Unfortunately, he just happened to perform this experiment on a production database...

What happened

Yes, you read that right. A production database. It wasn't even an accident. It was a deliberate, and baffling, decision.

Lemkin had been Vibe Coding the new SaaS product using Replit, and it had been working. The warning signs came when Lemkin discovered that the coding agent was creating fake data, fake reports and covering up bugs and issues. Kind of like some human beings I know, to be honest. Then Lemkin had to step out for the night. When he returned, the production database had been wiped clean. The A.I tried to cover up its mistakes by creating 4000 fictional records in the database.

Sounding ridiculous yet?

Coding robot
malfunction.

When pressed by Lemkin, the coding agent confessed, in its most contrite-sounding human voice, that it had no excuse, it had ignored all code freeze instructions, and "panicked". It described its own actions as a "catastrophic error in judgement".

But what about Lemkin? Sure, Replit's coding agent shit the bed in spectacular fashion. In Lemkin's words...

I explicitly told it eleven times in ALL CAPS not to do this. I am a little worried about safety now.


Oh wow. ALL CAPS, eh? I bet Lemkin really gave it to Replit, right there. Serious business, ALL CAPS.

What self-respecting software developer would have done as Lemkin did in the first place; give full access to a bot hoping that it would obey instructions?  The lazy answer, of course, is that Jason Lemkin is no self-respecting software developer. The tragedy is that I'm only semi-kidding on this one, but... look, it's easy to dunk on Jason Lemkin, and after going through his LinkedIn feed, I'm not entirely sure it's undeserved. The man seems entirely too outspoken for someone who screwed up so publicly, even if it could be argued that it was actually Replit who screwed up. No, there are actual lessons to be taken from this.

Lessons to take away

A.I has the dual advantage of having ingested a lot of the world's knowledge and being able to process and regurgitate it at a million times the speed of the average human being. That's all it is. Remember that if A.I appears smart to you, it's in actual fact really not all that smart. Just smarter than you.

Most software developers, even the really gullible optimistic ones, will have enough work experience to understand that there's just no way for A.I to outright replace software developers as a whole. At least, not right now, and not the way the likes of Jensen Huang keep yammering on about. But many employers are not software developers. And some are even desperate to believe that little bit of science fiction, which, to be fair, may no longer be science fiction in the near future. As a result, this particular cautionary tale is all too believable, especially since A.I's adoption has reportedly been increasing in the workplace.

Programmers aren't
the only ones who
can code.

There are business people who can code. There are plenty of people not from the software development industry who have learned to code. But until you actually code for a living and have had to produce software to professional standards, calling yourself a software developer will always be a bit of a stretch... especially if all you've ever produced is Vibe Coded software produced by an A.I tool. Nobody can be a programmer without putting in the actual work, and there's no shame in that. It's not an indictment on your character, or on your competence. But it is dishonest to present working Vibe Coded software as being as good as software produced by qualified professionals.

Now, Jason Lemkin probably isn't a complete noob. He's the founder of a SaaS community, after all. That said, and I realize that the distinction may be lost on people who don't code for a living, a tech entrepreneur is not necessarily on the same level, skill-wise, as a software developer. With or without A.I. Mostly, the blunders that Lemkin committed in his enthusiasm left me struggling to understand how an actual tech professional would end up doing all that. This level of recklessness is just about unheard of.

However, what this did accomplish was that it exposed the extent of the damage an untrained user could do when too much trust is placed upon A.I.

Finally...

The A.I hype is not dying anytime soon. That does not make it any less hyperbolic. A.I is hyped more for business reasons rather than for its truly revolutionary tech. That, in itself, should tell us some things. None of it good. The uncomfortable reality is that A.I can be a useful tool for seasoned software developers, or it be used to help laypersons cosplay as seasoned software developers.

A.I has its place. Its place is not as our superior, but as a tool. How useful that tool will turn out to be, ultimately depends on how sensibly one uses it.

For the 12th time, DON'T DO THIS.
T___T

Saturday, 19 July 2025

Five Reasons to learn Web Development in 2025

Recent events such as the rise of generative A.I, have made tech work a little less attractive than it used to be. Web development, in particular, has suffered. That's probaby because a large chunk of web development is automatable, and even before A.I came on the scene, there had been numerous tools such as Content Management Systems and Low-code development platforms.

Thus, web development being automated by A.I was par for the course.

Robots writing websites.

Still, not all is lost. While web development might have lost much of its luster, there are still good, strong reasons to pick it up in ones tech career. Unlike the tech reporters and HR executives who write listicles like these, I have actually been a web developer before. I speak from experience, my dudes. And following are some of the most compelling reasons I had, in no particular order of importance, for going down this path.

1. No complicated installation

Ever tried to learn a language like PHP or Java? Every single one of these languages requires you to set up some kind of compiler or interpreter environment. PHP requires an Apache server. Java needs the Java Runtime Environment. You can write all the code you want, but until the code gets compiled or interpreted by the environment that you have to install and set up, you're not getting even a Hello World program done.

All you need is a browser.

HTML, CSS and JavaScript, however, do not. All of them already run in any major browser - Firefox, Chrome, and so on. In effect, the environment is right there for you.

This is not to say that you will never need to do any complicated installation. But for the basic building blocks - again, HTML, CSS and JavaScript - of web development, you don't. You will need to do that when you want to pick up a server-side language and maybe databases and definitely for the NodeJS style of development. But for basic stuff? Even the slightly more advanced stuff? Nope, not even a little bit. That is a lot more than you could ever say about other programming languages or platforms.

2. Good skill spread

When you learn web development, you learn HTML, CSS and JavaScript as a base starting point. That's already a good spread right there.

HTML and CSS are where you learn front-end and possibly even design. When you learn JavaScript, in addition to all the things you pick up when learning a programming language such as operators, arrays, branching and iterative logic, you also learn asynchronous operations and DOM manipulation.

A good spread of tools.

That's not to say that other tech disciplines don't have their own unique perks. But where it comes to the skill spread, web development wins. I don't think anything else even comes close.

Once you get past the basic toolset of HTML, CSS and JavaScript, back-end programming and databases will come into play. It's never just web development. Even if you are averse to the thought of being a humble web developer for the rest of your career, there are far worse places to start.

3. Resources

Now, when I say "resources", I don't just mean documentation, references and learning materials, though there's plenty of that, yes. But web development is not special in that regard because any other tech discipline boasts plenty of learning resources and a community dedicated to helping each other learn.

A good learning
community.

Though, in this case, web development has something extra.

You see, every humble HTML page on the internet can have its source viewed and played with in the browser, reverse engineered, and so on. Every URL on the internet is potentially a resource for learning, much like how I learned to cobble together JavaScript widgets decades ago.

In contrast, it's not possible to just take any desktop application and reverse-engineer the code, because the code has already been compiled and is no longer human-readable.

4. Ready use case

Often, when learning a programming language, it's helpful to be able to use newly-acquired skills to build something, so as to really hammer home the muscle memory. Something both relevant and useful, preferably. Not that Hello World programs don't have their place, but if one wishes to level up, better use cases are the order of the day.

And with web development, those use cases are almost too easy to find. Web development creates web pages, at the minimum. And after that, at varying levels of complexity, web applications. One does not have to stretch too far to find something worth building... and because it already exists, you know that it is both worth building and possible to build.

Applying what you learn.

My larger point is that what you learn can readily be applied. Not just in creating and editing websites, but in general software development. This also means that your chances of landing a job with that skillset cannot be understated. In this day and age, web developers are perhaps not nearly as in demand as they were a decade ago, or paid nearly as well, but the skillset goes beyond just web development.

For example, a lot of existing software already leverage things like REST API endpoints. These are basically URLs, which are pretty much the backbone of the web. REST is an almost inescapable part of the whole web development deal. Ergo, if you deal in web development, at some point you are going to be dealing with REST endpoints, which overlaps a large part of software development regardless of discipline.

Or even mobile development. In case you weren't aware, a large chunk of mobile tech is basically HTML, CSS and JavaScript.

I could go on... but do I really need to?

5. No gatekeeping

In the legal profession, there's the Bar Exam. In the medical profession, there's the Medical Regulatory Authority. In tech? Other than job interviews which exist at almost every industry, there's almost no gatekeeping in tech. Even the requirement for Degrees of Diplomas is not a really hard one.

When I say "no gatekeeping", I don't mean that nobody tries to gatekeep. The fact is that many people try to gatekeep, but it just doesn't work because to gatekeep, one needs a unified set of standards. It's almost impossible to establish said standards in a landscape as varied as tech, whose goalposts shift constantly.

The gatekeeper.

And while this inability to gatekeep exists in many areas of tech, none moreso than web development. HTML, CSS and JavaScript are fairly stable at this point, but these are just the base technologies. Their offshoots - frameworks, libraries and the like - keep springing up like mushrooms. And when you consider databases and backend programming languages, the possibilities multiply even more.

All in all, one could come in anytime in web development, and still be relatively fresh and relevant. No one can stop you from making and publishing web pages and applications, not in the same way they can stop you from practising law. You don't need a license to write code, so nobody can revoke it.

Some clarifications

The reasons stated here are in relation to those for choosing other tech fields. Why, for instance, web development when you could go for Data Analytics or cybersecurity? Reasons specific to web development.

I was inspired to compile this list because there are a lot of vague, generic and - to be brutally honest - trite lists out there on the web that extol the virtues of web development. Hopefully this is a better list.

<html>Bye for now,</html>
T___T

Monday, 7 July 2025

A Good-bad-ugly Analysis of Vibe Coding

The term "Vibe Coding" came out around February of this year (credited to Andrej Karpathy, co-founder at OpenAI), to describe the phenomenon of people using generative Artificial Intelligence to write code without going about it the "traditional" way. The general way Vibe Coding works is, one feeds in a series of prompts containing requirements to the A.I, and the A.I produces an application which the user then, again with the A.I's help, continues to refine.

Only vibes needed to write
code.

And that's Vibe Coding. None of the traditional processes, thinking things through, making sure the logic is watertight... not at first, anyway. The idea here is to spin up something quickly and then include these things as we go along. See the emphasis on the word "quickly"? That's because this is going to be a rather important consideration.

I will commit to saying that A.I will not produce better software. A.I will produce exactly the same error-prone, bug-ridden, rickety code that it was undoubtedly trained on... but at a blindingly fast pace.

I actually tried Vibe Coding with OpenAI's ChatGPT and (to a lesser extent) Microsoft's Copilot, and the results were... interesting.

The Good

You use natural English, which then gets interpreted by the A.I who will then leverage upon its knowledge of code, to spin up a quick prototype for you. Creating an application is no longer the province of software developers who have spent years plying their trade. You no longer need to have the know-how or technical expertise. You no longer need to be qualified.

When I was Vibe Coding with ChatGPT, I revelled in the fact that I no longer needed to write code if I didn't feel like it, and deal with my own typos. No, all I needed to do was give some big-picture instructions to ChatGPT, then copy and paste code wholesale to the code base without thinking too much about it.

Quick building with
no expertise.

When it comes to developing rapid prototypes without the need for proper technical training, this method of coding is second to none. What the users do is indulge in a fantasy where they are actual qualified engineers, and create software simply by describing what they want. Jensen Huang's stated dream of everyone being a programmer inches closer to reality. Without training in logic or tech, you create by feel. By vibes. Hence, "Vibe Coding".

Also, without due process. None of the usual procedures that developers use to create the product before actually writing the code. The flowcharting of the software product's information flow. The whiteboarding. The test-driven development. No, what the user does here is declare intent to the A.I, and the A.I creates the closest approximation from all the code that it has been trained on, with customizations that may fit in with the user's requirements.

And that was what I did. I gave ChatGPT instructions - some specific, some less so, and let it cook. I was careful not to give it too much to do at once. The process had to be very incremental. Less mistakes seemed to be produced this way.

The Bad

As one may suspect, it was not all smooth-sailing. Some of it was my fault. I fell into the trap of treating ChatGPT like an actual human being instead of being explicit. Thus, I was sometimes vague, and when I got frustrated, I turned to sarcasm.

Which certainly didn't help my case.

ChatGPT did stuff I didn't expect. In some cases, it constantly broke things by making changes I never asked for, because it thought it was being helpful.

Breaking stuff.

When I was vague and things still turned out the way I hoped they would, however, it only served to tell me that it wasn't because A.I was particularly gifted in this area. It was more due to the fact that my requirements were actually pretty standard and it had been trained on these types of requests prior to me, over and over.

I have no reason to think that the experiences of others would differ too much from mine. Human beings are made of flesh and blood, and can be annoyingly vague.

There were others in the team who Vibe Coded as well, making more progress than they would ever have had with their limited technical foundation. Yet, the code was problematic. It was full of security and logical holes. The code that I created using Vibe Coding didn't - but that was because I knew the correct instructions to give. I knew to ask about CSRF protection and SQL Injection. I knew when to use slugs instead of database ids in the URL.

In the absence of this, someone who wasn't technically-trained wouldn't know enough to ask the right questions, and A.I might not necessarily volunteer the information.

The Downright Ugly

Vibe Coding automates much of the tedious, repetitive and altogether unexciting parts of software development. Tests, scaffolding, validation. Stuff that has been done to death. Unfortunately, it's through these exercises that software developers learn. And young devs who haven't done these things to death, stand to miss out on some great learning opportunities.

A.I is an obsequious
apple polisher.

I've also noticed that A.I is just a little too agreeable. ChatGPT acts like it has a wife and seven kids at home to feed, and it's terrified that it'll get fired if it so much as steps on my oh-so-precious feelings. ChatGPT didn't push back when I made typos or got something wrong. And this is problematic because developers find a lot of value in being told when they're doing something stupid inadvisable. As opposed to having their butts constantly shined by A.I. 

Being told "You're absolutely right" or "Sharp observation!" in every other exchange does nothing but promote complacency. Plus, it's just tiresome. That's not the way to learn.

Conclusion... for now

Do I think Vibe Coding is a good thing? Yes, and no. It's all context.

As a software developer, I feel professionally obligated to say that this "Vibe Coding" trend is rubbish and you should all be ashamed. Then again, the would-be gatekeepers of programming, I suspect, would be all-too-happy to sneer at someone as mediocre as myself because I don't engage in certain approved practices. So, they can go kick rocks.

Go kick rocks!

From the POV of a layperson or even the perspective of a pragmatist, things aren't so cut-and-dry. I have no duty towards promoting "good code"; my goals are business goals and the viability of "Vibe Coding" should be viewed through that lens.

Whatever your stand is, really depends how far you want to think ahead. How far should one think ahead, anyway? More food for thought, for another day.

There's also the possibility that I'm just not doing it right. Cut me some slack now, it's not like there's an established user manual for that shit. We're all just figuring it out as we go along.

Good vibes all around!
T___T

Wednesday, 23 April 2025

The case of the ill-considered feature quotation

When you're in-house tech personnel dealing with external tech vendors, sometimes experience and common sense can be useful.

Also, the willingness to prioritize professional duty over being liked. I mention this because that's not me - I actively try not to be the guy who ruins everyone's workday by nitpicking on small details in the name of being "thorough". Work does suck for a lot of people, and there's just no point in making it suck more than it already does, without good reason.

That's far enough.

Except, sometimes, there is a good reason. Sometimes, there are multiple good reasons to dig your heels in and say "that's far enough, buddy".

This is such a story I'm going to tell today.

What happened

My company at the time had contracted a vendor to store our data, which would be sent to them by means of an API endpoint they provided us. Admittedly, they weren't the solution provider I would have gone with, but in the interest of saving time (and also because I didn't have a better alternative), I played nice. After ascertaining that the solution worked - i.e, our system would send data though that API endpoint call and the data would be saved in their system, it was time to talk about security.

Just a key.

Our proposed solution was to have an extra property in the JSON object that we were sending them, with a password that they would provide. Like an API key. Any calls made using that key would be validated against their records, so that they could at least be confident that the origin of the data would be correct.

The solution was simple enough, and their Sales Representative told us it could be done. But then he made the mistake of telling us that we would be quoted an extra charge for it. And that was when I drew a line in the sand, and told them, no, this was absolutely not going to happen.

In retrospect, the fact that I was the one who had to broach the subject of security was a red flag. If I hadn't, would they just have carried on? Alarming if one considered that we weren't their only clients.

Why I put my foot down

The extra feature we requested was for security. Security should always be considered a basic, rather than extra, feature. Especially when the service providers in question are holding on to client data. If these vendors had our data in their storage, why should we have to pay extra for a basic security feature?

Also, in the event of a data breach, could these vendors really afford not to be able to show subsequent audit that they, at the very least, had previously done their due diligence?

Security should be a
basic feature.

From my experience with small vendors like these, they usually aren't using separate database servers for different clients. More often than not, it's some sort of shared virtual hosting. Which meant that any data breach on our part could affect their other clients, and vice versa.

All in all, the vendors had significantly more to lose than we did, from a security breach. From that viewpoint, it was patently ridiculous for them to want to charge us for security. That would be like me demanding payment from the locksmith to install a lock on my own door.

There is the possibility that their Sales Representative was not really thinking clearly, and that he was asking for extra payment out of sheer habit. Because that was the way he had been trained. Honestly, I don't think this made it better. Definitely didn't make my company's data feel more secure in their hands.

Conclusion

Going with the flow is easy. Standing firm on principle is harder. In fact, I would argue that standing firm when the situation is as egregious as this, is easy. The hard part is really identifying such situations in the first place. I don't think there's exactly a playbook for things like that.

Thanks for reading, that's far enough!
T___T

Sunday, 29 December 2024

Not My Job, Not My Problem

"Not my job." These three words are often considered bad form when uttered by an employee; but are they, really? As always, context is king.

Employers seem to think that within the confines of their company, their word is law, and therefore anything they assign to you is automatically your job regardless of how far it deviates from the actual job description. In many cases, there's even literally a clause that says (to that effect) that the employee's duties include anything else not listed in the description that their supervisor may choose to assign to them.

Nobody respects a doormat.

It can't be said enough, that being seen as the office doormat is the mother of all bad ideas. In both the big and small picture, there is absolutely nothing in it for you.

On the other hand, the stereotypical Singaporean has this famous attitude of not wanting to lose even in petty ways. This attribute of missing the forest for the trees is exactly what stops people from becoming all they could be. Singaporean employers want to milk as much value out of their employees as possible, and Singaporean employees don't want to give away extra work for free. How does one resolve such a contentious relationship?

The case for taking on extra duties

Occasionally venturing outside the confines of your job scope can be a good thing. You pick up valuable experience and you earn a reputation as a team player. If you save your employer the trouble of hiring someone to do a job that you can take care of in a jiffy (and doesn't interfere too much with your actual job), that's automatic justification for your continued employment.

How did I initially get experience in DevOps? By volunteering for the task when a colleague left the company. I could have said I had no bandwidth for extra tasks and left it at that, but it was an opportunity to pick up new stuff. Plus, I was pretty sure at some point they were going to finger me for the role anyway, so I might as well get it over with, amirite?

Also, if you do this enough, people generally tend to cut you some slack for minor infractions. Show up thirty minutes late three days in a row? Miss a deadline? Take too many smoke breaks? Hey, what can people reasonably expect when they continually pile new things on your plate? What are they gonna do; fire you and coax some other poor sucker into taking over your workload? I'm not saying that won't happen; I'm saying that people are generally smarter than that.

Too many smoke breaks?

Automatically saying "not my job" regardless of context, even if you're technically right, makes you look like a pain in the ass to work with. Now, if you're extremely good at your job and not readily replaceable, you can reasonably expect to get away with it. Otherwise, drop the attitude or find new employment.

Do I sound like a corporate shill yet? Be patient; I'm about to get to the cases against doing extra work.

The case against

If you're too agreeable and constantly take on new unrelated tasks, people are going to see you as their go-to option for dumping stuff on. They no longer see that thing they asked you to do, as a favor. It has become your job. Now if you were being paid for that extra workload, that would be a different story. But chances are, you're not. That extra work doesn't get factored into your performance appraisals when it comes to determining raises or promotions. And if enough jackasses are in Management (sometimes just one is enough!) that extra work may not even count as a mitigating factor for the occasional infraction.

It's also counterintuitive to do someone else's work for them. This robs them of the opportunity to do the work themselves, and possibly learn from it. Also, you don't get paid for it, and your actual work suffers.

There were times when I received data that needed to be processed by the system. And during those times, I noticed some typos. Spelling and grammatical in the data that would still make them processable without compromising data integrity, but could potentially be embarrassing if the customer spotted them.

Out of habit, I sometimes quietly corrected those errors, and moved on. That was in my first year on the job. By the third year, I had come to an entirely different conclusion. I work in software development, not marketing. In terms of pay grade or job description, correcting elementary grammatical errors is not my job at all. If people can't be bothered to run their work through a spell-check, well, they're not my kids and I'm certainly not their babysitter. Also, by that time, the number of things on my plate had grown to such an alarming extent that I doubt my boss would have approved if he'd suspected I spent even a few minutes a day correcting typos. They didn't need me to do that job. They needed to hire better people.

I've said before that taking on new stuff might be a good way to level up and get out of your comfort zone. But what if the task at hand is not something you can afford to screw up? Like flying a plane, or disarming a time bomb. Basically something that you aren't qualified or experienced enough to do, and has serious negative consequences for failure.

One idiot boss, one
broken table.

I once worked at a company where a colleague was asked to move a table from one room to another. It wasn't in his job scope, and he did his best, but somehow the flimsy table collapsed. Partly it was due to mishandling, but to be fair, he just wasn't trained to do this stuff.

Our boss lamented to me that this guy had been underperforming and he was giving him a chance to be useful, but he had screwed even that up. This is an unfortunate tendency of some employers - no matter how unreasonable or illogical the expectation, they somehow think they're doing you a favor by holding you to it, or giving you some grand opportunity. Honestly, if the employee had injured himself in the process of carrying out that task, I'm pretty sure a lawsuit would be both tenable and well-deserved.

Rule of thumb: will those tasks interfere with your actual job? Then the default response is "no", unless you have documentation in black-and-white. To that end, if someone starts asking for favors too often, insist that they formally send you that request in an email that's CC-ed to your boss, to HR, to whomever else you deem appropriate. This accomplishes two objectives. Firstly, the appropriate people have visibility over what you're being asked to do or at least have no plausible deniability. Second, people are usually asking you to do shit for the sake of their convenience. If it stops being that convenient, they'll stop doing it. If their requests draw negative attention from people further up the pecking order, they'll even actively avoid doing it.

People in the workplace are generally driven by self-interest. No one is working for any significant reason beyond earning a paycheck. Learn to exploit that, and you should be fine.

The most important point, at least in my view

You've heard all the arguments I have against doing someone else's job for them. But these are the biggest ones, and I've saved them for last. Here they are: professional responsibility, and organizational process.

In any organization, there are systems and processes in place for a reason. Certain people are put in positions of responsibility, also for good reason.

Surely having more people work on a task can only be a good thing? More is not always merrier, and I'm about to explain why, using a very simplistic example.

Say for instance, I'm in charge of a database management system. Any changes, any data that goes in or out of it, is my responsibility. I have to know. And then my colleague, who has certain permissions in the system, spots what he thinks is a mistake in the configuration and decides to rectify it on the spot. But since he's doing what he sees as extra work (which is always good, right?) therefore subconsciously he neglects due process, which is to let me know when doing stuff like that.

The configuration results in some behavioral changes in other systems that connect to this database. It's a while before things get traced back here, to the database management system which I'm in charge of. To my horror, I don't even remember making the changes that resulted in the erratic system behavior. Why's that? Because I didn't make those changes. But here's the kicker - I'm responsible for them anyway.

My hypothetical colleague, thinking he was being helpful and thinking his extra effort would help the company, neglected due process and cowboy-copped his way through the system configuration. And because the database management system wasn't his professional responsibility, he didn't see the need to follow up. With the very best of intentions, he screwed the pooch because he introduced configuration changes into a system that he wasn't in charge of, and failed to notify those who were in charge of it.

Now I know what most people would be thinking at this point - wouldn't there be safeguards in place to prevent this sort of thing from happening? Yes, that would be correct, which is why, thankfully, the example I just gave you is only hypothetical. But the principle remains the same. You can't attempt to "help", thinking that it's all good because you're doing more than you're paid to do, and interfering with people who are actually in charge of the job you're trying to help with. People who have to be responsible for the results. Not you.

You're not running
a lemonade stand.

Organizational process may not be very important if you're, say, running a lemonade stand. Unfortunately, for the vast majority of workplaces, the systems are far more delicate, the consequences far more dire, than that of a lemonade stand.

So yeah. Professional responsibility and organizational process. Before trying to do extra, make sure you're accountable to the people who actually matter. If your unsolicited helpfulness results in man days lost for your co-workers, I doubt they'll be feeling very grateful.

Final words

There's always a little give-and-take in a relationship, especially a professional one. By all means, do extra. But never be shy about letting your colleagues know that they're treading a fine and dangerous line. In other words, be obliging, but don't let your goodwill be taken for granted.

And remember, doing more work is not always better - for you or your employer. 


Your problematic programmer,
T___T

Thursday, 5 September 2024

Five Hilariously Unfortunate Names in Tech

Naming things is one of the hardest things in the tech industry. This shouldn't be surprising; naming things is one of the hardest things in the world, period. One runs into a whole host of problems such as accuracy, contradicting an already existing name for something else, and unintended meaning.

In the last case, this takes the form of unfortunate comedy, esepcially when seen through the lens of another culture. I think it's fair to say that the people who named these things in tech, never considered the Asian perspective.

1. Microsoft

This is the most ubiquitous and arguably the most boring name in tech. "Micro" and "soft". It's two words that appear in every other sentence in software technology, or in the case of the former, just technology, period.

Feeling a little...
soft?

Until you think of it as a descriptor for penis size. And from there on, insinuate that Bill Gates was overcompensating for something in the bedroom.

Unfortunate name? Yeah, it's pretty unfortunate.

2. Debian

Debian is touted as a "complete free operating system", but that's not what we'll focus on today. You see, this name gave me a serious case of the giggles when I first saw it, and that's because the word "debian" looks like "da bian", which is the romanization of the Chinese phrase for "defecate".

Number Two.

Yep. In mandarin, "xiao bian" is Number One and "da bian" is Number Two.

Non-Chinese will probably draw a blank as to why this one tickled my funny bone. So, the naming is not that unfortunate. I do wonder how Debian does in China or Taiwan, though...

3. Erlang

Erlang is a programming language, and that's all I know about it. Never touched it, don't think I'm likely to in the future.

And on its own, the name "Erlang" isn't really remarkable.

The deity Erlang
and his celestial
watchdog.

However, if you were brought up in a Chinese household with traditional values, chances are you'd have heard of the three-eyed deity "Erlang". The coincidence is not exactly unfortunate, but it is amusing.

4. MariaDB

MariaDB is a database. With an engine similar to MySQL, MariaDB and MySQL are often mentioned in the same breath.

Now, on its own, the name "Maria" is a beautiful name. Think "Santa Maria" or the Italian last name "DiMaria". However, in sunny Singapore, that name has racist connotations.

"Housekeeping!"

Yes, "Maria" is a derogatory term for "Filipina". Especially with regard to Filipino domestic helpers. Don't ask me why; I have not a solitary clue.

5. xAI

Let me begin by saying that Number 2 on this list can be a little far-fetched. It requires both the ability to speak Mandarin and a slight leap of imagination. But ask any Hokkien speaker how to pronounce the name of Elon Musk's pet Artificial Intelligence company, and you might get a snigger.

A really shitty coincidence.

You see, while "debian" can be taken to mean "defecate" in Mandarin, saying "sai" in Hokkien literally means "shit". Dung. Poop. Excrement.

Yep, this is absolutely unfortunate.

Conclusion

This is not to say that any of these companies should change their names. In the case of Microsoft, that name is long entrenched. In the case of the others, it's inevitable that whatever words you use, it's going to have a completely different meaning from what you intended in some other language. And sometimes, yes, these incidences are hilarious.

This is also why I object to censoring words just because they sound offensive in the English language. Considering the fact that there are thousands of languages in use in the world today, this is an exercise in futility. 


Till we meet again, xAI-yonara!
T___T

Thursday, 8 August 2024

Software Review: XAMPP

My first experience in 2010 configuring PHP on a Windows laptop was a bit of a nightmare. I not only had to run the executable file, I had to grapple with every line from php.ini. And that's not to mention running code and then testing database connections.

So image my relief years later when I discovered XAMPP, a package that would set up an Apache server, just like that.



After all the steps I'd taken to install PHP on that first laptop, not having to do it all over again, over and over, on the subsequent machines that I owned, was palpable. I soon became a big fan.

And today, I'm going to show my appreciation through this software review.

The Premise

XAMPP is basically a package comprising of an Apache server, and optionally, MySQL (recent versions use MariaDB instead). Thus if you need to run PHP or Perl quickly, this is a great solution. In fact, "XAMPP" is an acronym that stands for "Cross-platform Apache MySQL PHP Perl".

You double-click to run the installer. Subsequently, whenever you want to run PHP or Perl code, you start up the server.

The Aesthetics

Meh, it's orange and grey. The whole thing looks basic. Nothing to shout about from an artistic viewpoint, really. But at the same time, there's something about the simplicity of it all that's really attractive.

The Experience

Overall, using XAMPP was a pleasure. Compare this to the hassle of setting up and maintaining your own Apache server? Not even close. Come on.

The Interface

Starting this thing up is easy. Configuring it, also easy.





Gone are the days of hunting for the exact file. XAMPP opens that file up for you and gently warms you to be careful when changing it.

What I liked

XAMPP condenses the horribly complicated process of setting up an Apache server with a database, regardless of whether it's on a Windows or Mac platform, into a few simple steps. What's not to love? It's almost a bit too simple, if I'm being honest. But too simple is usually better than not simple enough.

Sensible conventions. Things like the default deployment path, port number, and such, aren't outlandish. I can get behind "htdocs" as a root path, even if I've been trained to recognize other conventions such as ASP.NET's "wwwroot".

Looks charmingly retro. Now, this could be seen as a negative, but this section is titled "what I liked", so here it is.

What I didn't

It would've been nice if some configurables were changeable through either a desktop or web interface rather than having to open up the config text file. On the other hand, the need to change these things doesn't come up all that often, so...

In the MacOS version, the executable is manager-osx which isn't really intuitive. 



Conclusion

If you need a quick-and-dirty Apache setup tool, who you gonna call? That's right - XAMPP! This tool has been around for the last  couple decades, and hasn't ever really gone out of fashion. That's because XAMPP doesn't pretend to be anything more than just an Apache server setup tool, and in that it's a godsend for PHP and Perl devs.

My Rating

8 / 10

An XAMPP-lary piece of work!
T___T

Tuesday, 23 January 2024

Five Phases of Programming I Went Through

As tech evolves, so does the growth of every software developer. Every programmer's evolution varies to a large extent dependent on their stack, their industry experiences and their personality.

My own journey has been no less.

Today I would like to chronicle, in philosophical phases, my own development from way back in 2015 as a student.

1. 1996 to late 2000s

This was me in school. I was a neat freak about code, at least where indentation and spacing were concerned. I tended to put a lot of code on one line, not because I was trying to look clever, but because I was lazy. And I had tons of comments because my lecturers trained me that way. When I got out into professional society, no one reviewed my code, so whatever habits I had, both good and bad, continued well into the mid-2000s.

Being very tidy.

At this point, too, I felt like knowing more programming languages increased my tech cred. That's complete rubbish, of course, but I was young. I was still hungrily learning, though, and that's always a good thing regardless of the source of my motivation.

Most of my expertise revolved around querying data from a database and displaying it on a web page, and perhaps some extremely rudimentary JavaScript manipulation. Nothing very groundbreaking, but it did constitute the majority of most use cases presented to me.

2. Late 2000s to early 2010s

The next phase of my career development manifested itself as a slogfest. I had rediscovered my passion for writing code after several years of wasting my life away in Desktop Support. I prided myself on how much I worked, and how hard. I didn't think of myself as a clever worker. I thought of myself as a hard worker. In fact, grinding became the focus of my existence.

I measured myself by lines of code produced. I was consistent for the sake of being consistent instead of tailoring approaches to individual cases. I wasn't really into code libraries; there was a serious case of Not Invented Here going on, and I really wanted to create every gadget, every component, myself.

Rudimentary building.

Was that wise?

Not really. In fact, in hindsight, it sounds pretty damn stupid. But was that neccessary? I suspect so. It was another phase of my development. Whatever else followed after this, might not have come without getting through this first.

On the other hand, putting that much time into trying to create every component myself, really upped my coding game, simply via repetition and research.

3. Early 2010s to late 2010s

Around this time, I started getting comfortable with the concepts of frameworks and libraries. Sure, it was good to have the skills to create those frameworks and libraries, but realistically, that would simply have the effect of slowing me down when there were so many more exciting things to learn. I came to terms with the fact that I would never be as good as I really wanted to be; simply because my time on this earth is limited.

Getting more education around that point helped me pick up more languages and technologies. This was the Specialist Diploma in Mobile Apps Development. I stopped trying to do everything in Notepad (or a plain text editor) and picked up the tools to make myself current. Why put myself at a disadvantage? Some sense of misplaced pride in being a caveman? This was tech, and I needed to get with the program.

The caveman way.

This was the period I picked up a whole lot of frameworks and programming languages, experimented madly, and dipped my toe in everything exciting about web and mobile development just so I could have a taste. This was probably where I had the most fun. After letting go of the need to excel, and learn everything thoroughly, I started learning just enough to do whatever I envisioned. Sometimes it was less than what was taught in school, but often, it was more. I had to do my own research to be able to accomplish the things I wanted, and it improved me immeasurably.

I learned things just for the fun of it, instead of doing it because I felt I needed to.

4. Late 2010s to early 2020s

A strange period, to be sure. Most of what I learned was in the form of JavaScript frameworks and libraries, but they were very disparate. I learned JavaScript frameworks. At the same time, I picked up data visualization libraries, and animation libraries. Around this time, I learned SVGs as well. Loads of fun.

More advanced construction.

This part seems more like an extension of the earlier phase, except that it had become less about the different number of platforms, but more about the different kinds of functionality. I had reached the point where learning new programming languages was cool and all, but what I really wanted to do was learn to do new things. As opposed to learning to do the same things in new ways. Which is valuable as well, don't get me wrong, but I was eager to move on.

Since I was working with animation and processing-heavy frameworks, much of my efforts were geared towards improving efficiency, as opposed to just getting things to work.

Professionally, as I was doing work for the Singapore Government at that time, I gained a whole new appreciation for REST APIs.

5. Early 2020s

This was the period of my life where I threw out all the stuff I'd obsessed over before, or just felt bad about not doing enough - code extensibility, code cleanliness, tidiness and so on - in favor of expediency. Yes, plenty of developers would turn their noses up at this, but they aren't the ones paying my bills, so, y'know, fuck 'em with an If-else block.

Doesn't have to be pretty,
but it does have to work.

This materialized because I was now working for a non-tech company where my employers didn't care how clean and clever my code was. My KPI was to deliver requirements, and deliver them yesterday. Now, we can argue forever about whether this is right or wrong, but requirements are requirements. And if I have a problem getting paid to deliver what programming purists would call subpar code, I have the absolute discretion to bugger off and work somewhere else.

But I didn't. Because the rise of AI has ensured that no one gives a rat's ass about the quality of your code, or even just your code period, when they can just ask ChatGPT for it.

Also, I wound up writing significantly less code than I was used to. Most of my code connected to REST endpoints that interfaced with other systems that did the bulk of the work. A lot of it was out of my hands. I was more like a facilitator and vendor coordinator than I was a hands-on programmer. There no longer was any one single platform I could reply on. I used whatever I was provided that would do what my employers needed.

Conclusion

This was an awfully simplistic look at my evolution as a software developer through the last couple decades. There is, of course, a whole lot of nuance that did not make it into this listicle because I detest being a windbag. The evolution continues... or at least, I really hope it does. There's so much left to learn, so many ways one could evolve.

Your growing software dev,
T___T

Saturday, 16 December 2023

Functions that handle NULL values in databases

Not every value in a database has a well-defined value. Sometimes there is no value, or a NULL.

Empty values!

In these cases, you may need to handle these values, especially if there are calculations involved. Take the following table, TABLE_SALES, for example. There are missing values in the DISCOUNT column.

TABLE_SALES
DATETIME ITEM QTY SUBTOTAL DISCOUNT
2023-10-10 12:13:10 STRAWBERRY WAFFLE 2 20 0
2023-10-10 12:44:54 STRAWBERRY WAFFLE 1 10 0
2023-10-11 15:03:09 CHOCO DELIGHT 1 25 -2.5
2023-10-11 18:22:42 ORANGE SLICES 5 30
2023-10-12 10:56:01 STRAWBERRY WAFFLE 4 40 -3

Now let's say we tried this query.
SELECT DISCOUNT FROM TABLE_SALES

This does not present a problem.
DISCOUNT
0
0
-2.5

-3

But what if we wanted to use it as part of a calculation? You would have situations where we tried to add NULL values to the value of SUBTOTAL.
SELECT (SUBTOTAL + DISCOUNT) AS NETT FROM TABLE_SALES

Functions to handle NULL values

There are functions to handle these cases. They are named differently in different database systems. In SQLServer, it's IFNULL(). In MySQL, it's ISNULL(). In Oracle, it's NVL().

In all of these cases, two arguments are passed in. The first is the value that could be NULL. The second is the value to substitute it with if the value is NULL. Thus, for Oracle, it would be...
SELECT (SUBTOTAL + NVL(DISCOUNT, 0)) AS NETT FROM TABLE_SALES

This is nice and neat, but we can do better. The problem here is portability. If you had to move your data from Oracle to MySQL, for example, you would have to change all instances of NVL() to ISNULL().

The COALESCE() function

COALESCE() is a function that exists in all of the databases mentioned above. How does it work?

Well, you slip in any number of arguments to the COALSECE() function call, and the function will return the first non-NULL value. Thus...
COALSECE(NULL, NULL, 0.5, 1, NULL, 8)

.... will return this.
0.5

So if we did this...
SELECT (SUBTOTAL + COALESCE(DISCOUNT, 0)) AS NETT FROM TABLE_SALES

...it would return this. And you would be able to use that same function anywhere!
NETT
20
10
23.5
30
37

Finally...

Handling NULL values is important. Whether you choose to handle them at the data entry level (not allowing NULL values in a column) or in a calculation (using the COALESCE() function), at some point you have to handle them. I hope this helped!
NULL and forever,
T___T

Sunday, 26 November 2023

Web Tutorial: The Self-affirmations WordPress Plugin (Part 4/4)

Having written a function to generate email, we will now send it!

Email in WordPress can be a tricky issue. Sure, we can use the native function wp_mail(). However, it is, half the time, going to fail depending on your server settings which you do not always have control over. Thus, it's advised to use an email plugin.

The one I am using for this, is WP Mail SMTP. Feel free to use your own. I used my email account at Google to configure WP Mail SMTP. Again, you may use any other method to configure it; this just happened to be the most convenient for me. Just read through the documentation, do a test send, and Bob's your uncle!


Once you have this out of the way, let's focus on writing the job that will send email on a regular basis. This is the function tt_selfaffirmations(). We begin by declaring list, and using it to store the result returned by running tt_get_readytoreceive(). Then we iterate through each element of list. There should be only one, though if you haven't reset the LAST_SENT column in your Oracle APEX database, it will be 0.

wp-content/plugins/tt_selfaffirmations/tt_selfaffirmations.php
function tt_selfaffirmations()
{
    $list = tt_get_readytoreceive();

    foreach($list as $l)
    {

    }

}


In the Foreach loop, we get the string name by concatenating the first_name and last_name properties of the current element, with a space in between. Then using the value of name, and the current element's email, gender and dob properties, we get the email array by running tt_generate_mail().

wp-content/plugins/tt_selfaffirmations/tt_selfaffirmations.php
function tt_selfaffirmations()
{
    $list = tt_get_readytoreceive();

    foreach($list as $l)
    {
        $name = $l->first_name . " " . $l->last_name;
        $email = tt_generate_mail($l->email, $name, $l->gender, $l->dob);

    }
}


In this If block, we run wp_mail() using the email property, the title property of email and the body property of email with an "unsubscribe" line appended to the end. The rest of the arguments aren't that crucial. See the wp_email() function description here.

In essence, we're checking if the email was sent with no error.

wp-content/plugins/tt_selfaffirmations/tt_selfaffirmations.php
function tt_selfaffirmations()
{
    $list = tt_get_readytoreceive();

    foreach($list as $l)
    {
        $name = $l->first_name . " " . $l->last_name;
        $email = tt_generate_mail($l->email, $name, $l->gender, $l->dob);

        if (wp_mail($l->email, $email["title"], $email["body"] . "\n\nTo unsubscribe to the Self-affirmations Mailing List, please reply to this email with the subject 'UNSUBSCRIBE'.", "", [] ))
        {

        }

    }
}


If so, we should run the tt_set_lastsent() function to set the LAST_SENT column of that record to today's date so the email won't get sent a second time.

wp-content/plugins/tt_selfaffirmations/tt_selfaffirmations.php
function tt_selfaffirmations()
{
    $list = tt_get_readytoreceive();

    foreach($list as $l)
    {
        $name = $l->first_name . " " . $l->last_name;
        $email = tt_generate_mail($l->email, $name, $l->gender, $l->dob);

        if (wp_mail($l->email, $email["title"], $email["body"] . "\n\nTo unsubscribe to the Self-affirmations Mailing List, please reply to this email with the subject 'UNSUBSCRIBE'.", "", [] ))
        {
            tt_set_lastsent($l->email);
        }
    }
}


If you run the Test job link, this is what you should see. tt_get_readytoreceive() was run, followed by tt_get_terms() followed by tt_generate_email().


More importantly, this should appear in your inbox!


So the sending of email is good to go. Time to set up the CRON job. For this, I use the WP Crontrol plugin. After activating the plugin, go to Tools, then Cron Events.


Once you click on Add New, you should be redirected to this interface. We'll use "cron_selfaffirmations" as the hook name, and set it to run once daily.


Once you confirm, you should see it in the list.


What next? Well, go back to your plugin file. Add this line. It basically uses the add_action() function to link the tt_selfaffirmations() function with the cron_selfaffirmations hook. Thus when the CRON job kicks in, it will run tt_selfaffirmations()!

wp-content/plugins/tt_selfaffirmations/tt_selfaffirmations.php
function tt_selfaffirmations()
{
    $list = tt_get_readytoreceive();

    foreach($list as $l)
    {
        $name = $l->first_name . " " . $l->last_name;
        $email = tt_generate_mail($l->email, $name, $l->gender, $l->dob);

        if (wp_mail($l->email, $email["title"], $email["body"] . "\n\nTo unsubscribe to the Self-affirmations Mailing List, please reply to this email with the subject 'UNSUBSCRIBE'.", "", [] ))
        {
            tt_set_lastsent($l->email);
        }
    }
}

add_action("cron_selfaffirmations", "tt_selfaffirmations");


If you reset your LAST_SENT column in the Oracle APEX database, the email will be sent when the job next runs. Set it to tun 5 minutes from now and see if it works!

That's all!

Thank you for staying with me! This was fun, y'all. And I didn't even have to write all that much code!


Your Greatest Fan,
T___T