Tag: automation

Seven to five years ago, I was absolutely obsessed with the idea of beating the stock market. I dove headfirst into the world of investing, devouring books, blogs, and whatever information I could get my hands on. I was like a sponge, soaking up everything. After countless hours of research, I came to one clear conclusion:

To consistently beat the market, I needed a unique edge—some kind of knowledge advantage that others didn’t have.

It’s like insider trading, but, you know, without the illegal part. My plans to uncover obscure data and resources online that only a select few were using. That way, I’d have a significant edge over the average trader. In hindsight, I’m pretty sure that’s what big hedge funds, especially the short-selling ones, are doing—just with a ton more money and resources than I had. But I’ve always thought, “If someone else can do it, so can I.” At the end of the day, those hedge fund managers are just people too, right?

Around that time, I was really into the movie War Dogs. It had this fascinating angle that got me thinking about analyzing the weapons trade, aka the “defense” sector.

Here’s the interesting part: The United States is surprisingly transparent when it comes to defense spending. They even publicly list their contracts online (check out the U.S. Department of Defense Contracts page). The EU, on the other hand, is a completely different story. Getting similar information was like pulling teeth. You’d basically need to lawyer up and start writing formal letters to access anything remotely useful.

The Idea

Quite simply: Build a tool that scrapes the Department of Defense contracts website and checks if any of the publicly traded companies involved had landed massive new contracts or reported significantly higher income compared to the previous quarter.

Based on the findings, I’d trade CALL or PUT options. If the company performed poorly in the quarter or year, I’d go for a PUT option. If they performed exceptionally well, I’d opt for a CALL, banking on the assumption that these contracts would positively influence the next earnings report.

Theoretically, this seemed like one of those obvious, no-brainer strategies that had to work. Kind of like skipping carbs at a buffet and only loading up on meat to get your money’s worth.

Technologie

At first, I did everything manually with Excel. Eventually, I wrote a Python Selenium script to automate the process.

Here’s the main script I used to test the scraping:

// Search -> KEYWORD
// https://www.defense.gov/Newsroom/Contracts/Search/KEYWORD/
// -------
// Example:
// https://www.defense.gov/Newsroom/Contracts/Search/Boeing/
// ------------------------------------------------------------

// All Contracts -> PAGE (momentan bis 136)
// https://www.defense.gov/Newsroom/Contracts/?Page=PAGE
// -------
// Example:
// https://www.defense.gov/Newsroom/Contracts/?Page=1
// https://www.defense.gov/Newsroom/Contracts/?Page=136
// -------------------------------------------------------

// Contract -> DATE
// https://www.defense.gov/Newsroom/Contracts/Contract/Article/DATE
// -------
// https://www.defense.gov/Newsroom/Contracts/Contract/Article/2041268/
// ---------------------------------------------------------------------

// Select Text from Article Page
// document.querySelector(".body")

// get current link
// window.location.href



// ---> Save Company with money for each day in db

// https://www.defense.gov/Newsroom/Contracts/Contract/Article/1954307/
var COMPANY_NAME = "The Boeing Co.";
var comp_money = 0;
var interesting_div = document.querySelector('.body')
var all_contracts = interesting_div.querySelectorAll("p"),i;
var text_or_heading;
var heading;
var text;
var name_regex = /^([^,]+)/gm;
var price_regex = /\$([0-9]{1,3},*)+/gm;
var price_contract_regex =/\$([0-9]{1,3},*)+ (?<=)([^\s]+)/gm;
var company_name;
var company_article;

for (i = 0; i < all_contracts.length; ++i) {
  text_or_heading = all_contracts[i];

  if (text_or_heading.getAttribute('id') != "skip-target-holder") {
  	if (text_or_heading.getAttribute('style')) {
  		heading = text_or_heading.innerText;
  	} else {
  		text = text_or_heading.innerText;
	    company_name = text.match(name_regex)
	    contract_price = text.match(price_regex)
	    contract_type = text.match(price_contract_regex)

	    try {
	    	contract_type = contract_type[0];
	    	clean_type = contract_type.split(' ');
	    	contract_type = clean_type[1];
	    } catch(e) {
	    	contract_type = "null";
	    }
	    try {
	    	company_article = company_name[0];
	    } catch(e) {
	    	company_article = "null";
	    }
	    try {
	    	contract_amount = contract_price[0];
		    if (company_article == COMPANY_NAME){
		    	contract_amount = contract_amount.replace("$","")
		    	contract_amount = contract_amount.replace(",","")
		    	contract_amount = contract_amount.replace(",","")
		    	contract_amount = contract_amount.replace(",","")
		    	contract_amount = parseInt(contract_amount, 10)


		    	comp_money = contract_amount + comp_money
	    	}
	    } catch(e) {
	    	contract_amount = "$0";
	    }

	    console.log("Heading      : " + heading);
	    console.log("Text         : " + text);
	    console.log("Company Name : " + company_article);
	    console.log("Awarded      : " + contract_amount)
	    console.log("Contract Type: " + contract_type);
  	}
  }
}
console.log(COMPANY_NAME);
console.log(new Intl.NumberFormat('en-EN', { style: 'currency', currency: 'USD' }).format(comp_money));



// --> Save all Links to Table in Database
for (var i = 1; i >= 136; i++) {
	var url = "https://www.defense.gov/Newsroom/Contracts/?Page=" + i

	var  page_links = document.querySelector("#alist > div.alist-inner.alist-more-here")
	var all_links   = page_links.querySelectorAll("a.title")

	all_links.forEach(page_link => {
		var contract_date = Date(Date.parse(page_link.innerText))
		var contracvt_link = page_link.href
	});
}

The main code is part of another project I called “Wallabe“.

The stack was the usual:

• Python: The backbone of the project, handling the scraping logic and data processing efficiently.
• Django: Used for creating the web framework and managing the backend, including the database and API integrations.
• Selenium & BeautifulSoup: Selenium was used for dynamic interactions with web pages, while BeautifulSoup handled the parsing and extraction of relevant data from the HTML.
• PWA (“mobile app”): Designed as a mobile-only Progressive Web App to deliver a seamless, app-like experience without requiring actual app store deployment.

I wanted the feel of a mobile app without the hassle of actual app development.

One of the challenges I faced was parsing and categorizing the HTML by U.S. military branches. There are a lot, and I’m sure I didn’t get them all, but here’s the list I was working with seven years ago (thanks, JROTC):

millitary_branch = {'airforce',
                    'defenselogisticsagency',
                    'navy',
                    'army',
                    'spacedevelopmentagency',
                    'defensemicroelectronicsactivity',  
                    'jointartificialintelligencecenter',      
                    'defenseintelligenceagency',
                    'defenseinformationsystemagency',
                    'defensecommissaryagency',
                    'missiledefenseagency',
                    'defensehealthagency',
                    'u.s.specialoperationscommand',
                    'defensethreatreductionagency',
                    'defensefinanceandaccountingservice',
                    'defenseinformationsystemsagency',
                    'defenseadvancedresearchprojectsagency',
                    'washingtonheadquartersservices',
                    'defensehumanresourceactivity',
                    'defensefinanceandaccountingservices',
                    'defensesecurityservice',
                    'uniformedservicesuniversityofthehealthsciences',
                    'missledefenseagency',
                    'defensecounterintelligenceandsecurityagency',
                    'washingtonheadquartersservice',
                    'departmentofdefenseeducationactivity',
                    'u.s.transportationcommand'}

I tried to revive this old project, but unfortunately, I can’t show you what the DoD data looked like anymore since the scraper broke after some HTML changes on their contracts website. On the bright side, I can still share some of the awesome UI designs I created for it seven years ago:

Imagine a clean, simple table with a list of companies on one side and a number next to each one showing how much they made in the current quarter.

How it works

Every day, I scrape the Department of Defense contracts and calculate how much money publicly traded companies received from the U.S. government. This gives me a snapshot of their revenue before quarterly earnings are released. If the numbers are up, I buy CALL options; if they’re down, I buy PUT options.

The hardest part of this process is dealing with the sheer volume of updates. They don’t just release new contracts—there are tons of adjustments, cancellations, and modifications. Accounting for these is tricky because the contracts aren’t exactly easy to parse. Still, I decided it was worth giving it a shot.

Now, here’s an important note: U.S. defense companies also make a lot of money from other countries, not just the U.S. military. In fact, the U.S. isn’t even always their biggest contributor. Unfortunately, as I mentioned earlier, other countries are far less transparent about their military spending. This lack of data is disappointing and limits the scope of the analysis.

Despite these challenges, I figured I’d test the idea on paper and backtest it to see how it performed.

Conclusion

TL;DR: Did not work.

The correlation I found between these contracts and earnings just wasn’t there. Even when the numbers matched and I got the part right that “Company made great profit,” the market would still turn around and say, “Yeah, but it’s 2% short of what we expected. We wanted +100%, and a measly +98% is disappointing… SELLLL!”

The only “free money glitch” I’ve ever come across is what I’m doing with Bearbot, plus some tiny bond tricks that can get you super small monthly profits (like 0.10% to 0.30% a month).

That said, this analysis still made me question whether everything is truly priced in or if there are still knowledge gaps to exploit. The truth is, you never really know if something will work until you try. Sure, you can backtest, but that’s more for peace of mind. Historical data can’t predict the future. A drought killing 80% of cocoa beans next year is just as possible as a record harvest. Heck, what’s stopping someone from flying to Brazil and burning down half the coffee fields to drive up coffee bean prices? It’s all just as unpredictable as them not doing that (probably, please don’t).

What I’m saying is, a strategy that’s worked for 10 years can break tomorrow or keep working. Unless you have insider info that others don’t, it’s largely luck. Sometimes your strategy seems brilliant just because it got lucky a few times—not because you cracked the Wall Street code.

I firmly believe there are market conditions that can be exploited for profit, especially in complex derivatives trading. A lot of people trade these, but few really understand how they work, which leads to weird price discrepancies—especially with less liquid stocks. I also believe I’ve found one of these “issues” in the market: a specific set of conditions where certain instruments, in certain environments, are ripe for profit with minimal probability if risk (which means: high risk that almost never materializes). That’s Bearbot.

Anyway, long story short, this whole experiment is part of what got Bearbot started. Thanks for reading, diamond hands 💎🙌 to the moon, and love ya ❤️✌️! Byeeeee!

Five years ago, a younger and more optimistic Karl, with dreams of cracking the European equivalent of the Powerball, formed a bold thesis:

“Surely the Eurojackpot isn’t truly random anymore. It must be calculated by a machine! And since machines are only capable of generating pseudorandom numbers, I could theoretically simulate the system long enough to identify patterns or at least tilt the odds in my favor by avoiding the least random combinations.“

This idea took root after I learned an intriguing fact about computers: they can’t generate true randomness. Being deterministic machines, they rely on algorithms to create pseudorandom numbers, which only appear random but are entirely predictable if you know the initial value (seed). True randomness, on the other hand, requires inputs from inherently unpredictable sources, like atmospheric noise or quantum phenomena—things computers don’t have by default.

My favorite example of true randomness is how Cloudflare, the internet security company, uses a mesmerizing wall of lava lamps to create randomness. The constantly changing light patterns from the lava lamps are captured by cameras and converted into random numbers. It’s a perfect blend of physics and computing, and honestly, a geeky work of art!

Technologies

• Python: The backbone of the project. Python’s versatility and extensive library support made it the ideal choice for building the bot. It handled everything from script automation to data parsing. You can learn more about Python at python.org.
• Selenium: Selenium was crucial for automating browser interactions. It allowed the bot to navigate Lotto24 and fill out the lottery forms. If you’re interested in web automation, check out Selenium’s documentation here.

I was storing the numbers in an SQLite database, don’t ask me why, I think I just felt like playing with SQL.

The Plan

The plan was simple. I researched Eurojackpot strategies and created a small program to generate lottery numbers based on historical data and “winning tactics.” The idea? Simulate the lottery process 50 billion times and identify the numbers that were “randomly” picked most often. Then, I’d play the top X combinations that showed up consistently.

At the time, I was part of a lottery pool with a group of friends, which gave us a collective budget of nearly €1,000 per run. To streamline the process (and save my sanity), I wrote a helper script that automatically entered the selected numbers on the lottery’s online platform.

If you’re curious about the code, you can check it out here. It’s not overly complicated:

👉 GitHub Repository

Winnings

In the end, I didn’t win the Eurojackpot (yet 😉). But for a while, I thought I was onto something because I kept winning—kind of. My script wasn’t a groundbreaking success; I was simply winning small amounts frequently because I was playing so many combinations. It gave me the illusion of success, but the truth was far less impressive.

A friend later explained the flaw in my thinking. I had fallen for a common misunderstanding about probability and randomness. Here’s the key takeaway: every possible combination of numbers in a lottery—no matter how “patterned” or “random” it seems—has the exact same chance of being drawn.

For example, the combination 1-2-3-4-5 feels unnatural or “unlikely” because it looks ordered and predictable, while 7-23-41-56-88 appears random. But both have the same probability of being selected in a random draw. The fallacy lies in equating “how random something looks” with “how random it actually is.”

Humans are naturally biased to see patterns and avoid things that don’t look random, even when randomness doesn’t work that way. In a lottery like Eurojackpot, where the numbers are drawn independently, no combination is more or less likely than another. The randomness of the draw is entirely impartial to how we perceive the numbers.

So while my script made me feel like I was gaming the system, all I was really doing was casting a wider net—more tickets meant more chances to win small prizes, but it didn’t change the underlying odds of hitting the jackpot. In the end, the only real lesson I gained was a better understanding of randomness (and a lighter wallet).

This little experiment wasn’t meant to encourage cheating—far from it. It actually began as a casual conversation with a colleague about just how “cheatable” online tests can be. Curiosity got the better of me, and one thing led to another.

If you’ve come across my earlier post, “Get an A on Moodle Without Breaking a Sweat!” you already know that exploring the boundaries of these platforms isn’t exactly new territory for me. I’ve been down this road before, always driven by curiosity and a love for tinkering with systems (not to mention learning how they work from the inside out).

This specific tool, the LinkedIn-Skillbot, is a project I played with a few years ago. While the bot is now three years old and might not be functional anymore, I did test it back in the day using a throwaway LinkedIn account. And yes, it worked like a charm. If you’re curious about the original repository, it was hosted here: https://github.com/Ebazhanov/linkedin-skill-assessments-quizzes. (Just a heads-up: the repo has since moved.)

Technologies

This project wouldn’t have been possible without the following tools and platforms:

• Python: The backbone of the project. Python’s versatility and extensive library support made it the ideal choice for building the bot. It handled everything from script automation to data parsing. You can learn more about Python at python.org.
• Selenium: Selenium was crucial for automating browser interactions. It allowed the bot to navigate LinkedIn, answer quiz questions, and simulate user actions in a seamless way. If you’re interested in web automation, check out Selenium’s documentation here.
• LinkedIn (kind of): While LinkedIn itself wasn’t a direct tool, its skill assessment feature was the target of this experiment. This project interacted with LinkedIn’s platform via automated scripts to complete the quizzes.

How it works

To get the LinkedIn-Skillbot up and running, I had to tackle a couple of major challenges. First, I needed to parse the Markdown answers from the assessment-quiz repository. Then, I built a web driver (essentially a scraper) that could navigate LinkedIn without getting blocked—which, as you can imagine, was easier said than done.

Testing was a nightmare. LinkedIn’s blocks kicked in frequently, and I had to endure a lot of waiting periods. Plus, the repository’s answers weren’t a perfect match to LinkedIn’s questions. Minor discrepancies like typos or extra spaces were no big deal for a human, but they threw the bot off completely. For example:

"Is earth round?" ≠ "Is earth round ?"

That one tiny space could break everything. To overcome this, I implemented a fuzzy matching system using Levenshtein Distance.

Levenshtein Distance measures the number of small edits (insertions, deletions, or substitutions) needed to transform one string into another. Here’s a breakdown:

• Insertions: Adding a letter.
• Deletions: Removing a letter.
• Substitutions: Replacing one letter with another.

For example, to turn “kitten” into “sitting”:

1. Replace “k” with “s” → 1 edit.
2. Replace “e” with “i” → 1 edit.
3. Add “g” → 1 edit.

Total edits: 3. So, the Levenshtein Distance is 3.

Using this technique, I was able to identify the closest match for each question or answer in the repository. This eliminated mismatches entirely and ensured the bot performed accurately.

Here’s the code I used to implement this fuzzy matching system:

import numpy as np

def levenshtein_ratio_and_distance(s, t, ratio_calc = False):
    rows = len(s)+1
    cols = len(t)+1
    distance = np.zeros((rows,cols),dtype = int)

    for i in range(1, rows):
        for k in range(1,cols):
            distance[i][0] = i
            distance[0][k] = k
  
    for col in range(1, cols):
        for row in range(1, rows):
            if s[row-1] == t[col-1]:
                cost = 0 
            else:
                if ratio_calc == True:
                    cost = 2
                else:
                    cost = 1
            distance[row][col] = min(distance[row-1][col] + 1,
                                 distance[row][col-1] + 1,
                                 distance[row-1][col-1] + cost)
    if ratio_calc == True:
        Ratio = ((len(s)+len(t)) - distance[row][col]) / (len(s)+len(t))
        return Ratio
    else:
        return distance[row][col]

• levenshtein.py

I also added a failsafe mode that searches for an answer in all documents possible. If it can’t be found, the bot quits the question and lets you answer it manually.

Conclusion

This project was made to show how easy it is to cheat on online tests such as the LinkedIn skill assessments. I am not sure if things have changed in the last 3 years, but back then it was easily possible to finish almost all of them in the top ranks.

I have not pursued the cheating of online exams any further as I found my time to be used better on other projects. However, it did teach me a lot about fuzzy matching of strings and, back then, web scraping as well as getting around bot detection mechanisms. These are skills that have helped me a lot in my cybersecurity career thus far.

Try it out here: https://github.com/StasonJatham/linkedin-skillbot

Ah, Moodle quizzes. Love them or hate them, they’re a staple of modern education. Back in the day, when I was a student navigating the endless barrage of quizzes, I created a little trick to make life easier. Now, I’m sharing it with you—meet the Moodle Solver, a simple, cheeky tool that automates quiz-solving with the help of bookmarklets. Let’s dive into the how, the why, and the fine print.

You can check out the code on my GitHub here: https://github.com/StasonJatham/moodle_solver

I should note that this code is quite old and would need a lot of tweaking to work again.

What is Moodle Solver?

The Moodle Solver is a set of JavaScript scripts you can save as bookmarklets. These scripts automate the process of taking Moodle quizzes, saving you time, clicks, and maybe a bit of stress.

The basic idea:

1. Do a random first attempt on a quiz to see the correct answers.
2. Use the scripts to save those answers.
3. Automatically fill in the correct answers on the next attempt and ace the quiz.

How It Works

Step 1: Do the Quiz (Badly)

Most Moodle quizzes give you two or more attempts. On the first attempt, go in blind—pick random answers without worrying about the outcome. If you’re feeling adventurous, I even have a script that fills in random answers for you (not included in the repo, but it’s out there).

Why do this? Because Moodle shows you the correct answers on the review page after the first try. That’s where the magic happens.

Step 2: Run get_answers_german.js

Once you’re on the review page, it’s time to run the get_answers_german.js script. This script scans the page, identifies the correct answers, and saves them to your browser’s localStorage.

One caveat: The script is written in German (a throwback to my school days), so you might need to modify it for your language. Moodle’s HTML structure might also change over time, but a little tweaking should do the trick.

Step 3: Nail the Second Attempt

When you’re ready for your second attempt, use the set_answers.js script. This script fills in all the correct answers for you. Want to go full automation? Use autosubmit.js to submit the quiz with a randomized timer, so it doesn’t look suspicious. After all, no teacher will believe you aced a 50-question quiz in 4 seconds.

Bonus Features

Got the answers from a friend or Google? No problem. The fallback_total.js script lets you preload question-answer pairs manually. Simply format them like this:

  var cheater = {
    answers: [
      {
        question:
          "Thisisanexamplequestion?",
        answer: "thecorrectanswer",
      },
      {
        question: "Whatisthisexamplequestion?",
        answer: "youwillpass.",
      },
      {
        question: "Justlikethis?",
        answer: "yes,dude.",
      },
      .......
    ],
  };

Swap out the default questions and answers in the script, save it as a bookmarklet, and you’re good to go.

Why Bookmarklets?

Bookmarklets are incredibly convenient for this kind of task. They let you run JavaScript on any webpage directly from your browser’s bookmarks bar. It’s quick, easy, and doesn’t require you to mess around with browser extensions. It is also really sneaky in class 😈

To turn the Moodle Solver scripts into bookmarklets, use this free tool.

1. Download the Scripts: Grab the code from my GitHub repo: github.com/StasonJatham/moodle_solver.
2. Convert to Bookmarklets: Use the guide linked above to save each script as a bookmarklet in your browser.
3. Test and Tweak: Depending on your Moodle setup, you might need to adjust the scripts slightly (e.g., to account for language or HTML changes).

The Fine Print

Let’s be real: This script is a bit cheeky. Use it responsibly and with caution. The goal here isn’t to cheat your way through life—it’s to save time on tedious tasks so you can focus on learning the stuff that matters.

That said, automation is a skill in itself. By using this tool, you’re not just “solving Moodle quizzes”—you’re learning how to script, automate, and work smarter.

Wrapping Up

The Moodle Solver is a lighthearted way to make Moodle quizzes less of a hassle. Whether you’re looking to save time, learn automation, or just impress your friends with your tech skills, it’s a handy tool to have in your back pocket.

Check it out:

• GitHub Repo: github.com/StasonJatham/moodle_solver

Good luck out there, and remember: Work smarter, not harder! 🚀