DEV Community: Suleyman Sade

When the Market Takes Weekends Off - Devlog Stocksimpy

Suleyman Sade — Fri, 31 Oct 2025 22:37:03 +0000

I recently took a long break from working on StockSimPy — school got busy and pulled me away — but I’m back. The project is getting closer to the finish line, yet somehow the closer I get, the further it feels. The core components — backtesting, portfolio management, and stock data handling — are semi-functional, but parts like importing data from yfinance and cleaning it still need fixes, along with a few unexpected bugs.

Why Add Performance Metrics?

When I first planned StockSimPy, I didn’t think about including a dedicated performance class. I figured total return and a price graph would be enough. That changed after someone commented on one of my previous devlogs, asking if I planned to add metrics like the Sortino ratio.

That question stuck with me. I thought: If I were someone testing a trading strategy, would I want performance metrics? The answer was obviously yes. So, I researched what to include. For the initial release, I wanted just enough metrics to make the analysis meaningful without overcomplicating it. I settled on three: volatility, Sharpe ratio, and maximum drawdown.

This was my first time implementing these metrics, so I kept things simple — but not everything went smoothly.

Challenge #1: Counting Days

The stock market isn’t open every day. There are weekends, federal holidays, and random closures, which complicate calculating metrics like the Sharpe ratio and annualized return. I initially assumed that yfinance data only included trading days, but I needed to confirm how many actual trading days the backtest covered.

Then it hit me: my DataFrame already contained the portfolio value for each recorded date. By subtracting the first date from the last, I could find the total number of days in the simulation. From there, it was straightforward to plug that into the formula for annualized return. (I used an external resource for the math.)

Challenge #2: AI Boundaries

I didn’t want StockSimPy to turn into a “vibe-coded” AI-assisted project. My rule was to only use AI for documentation, examples, and code formatting. At first, that worked great — it helped generate detailed documentation and catch small formatting inconsistencies. But after a while, I noticed my calculations were returning wrong results. Turns out, the AI reformatted some logic incorrectly. Luckily, I had staged my changes beforehand, so rolling back was painless.

Challenge #3: Confirming the Accuracy of the Results

To do this, I chose some stocks and checked their data on these performance metrics for the 1Y range. Then I ran my backtesting for 1Y, buying as many stocks as possible on day 1 — emphasis on day 1. Most of the data was close enough, except for the total return, which differed by about 10% in some extreme cases.

I tried to figure out what was going wrong, and it turns out my code was running the backtest for 364 days instead of a full year. The initial date when all the stock was bought was on a Monday, meaning there was a decent price difference between that Monday and the previous Friday, which caused a surprisingly large difference once it was compounded over the entire year.

Conclusion

Overall, these challenges taught me that the accuracy of a finance project isn’t about the code, but the tiny assumptions buried in the data. With every print statement that I used to debug and fix errors, stocksimpy gets closer to being a reliable tool. There is still a lot more to develop…

If there is anything you want me to add, or any suggestions. Please reach out to me on my socials, or comment below 👇. It really helps with improving the library.

If you would like to support me:

⭐ Star stocksimpy on Github
📰 Read more of my posts on Medium
💬 Let’s connect on LinkedIn
📱 And on Instagram

Thanks for reading. Let me know what else you would suggest I add before the initial release.

Understanding and Coding a Swerve Module in FRC

Suleyman Sade — Sun, 19 Oct 2025 04:02:21 +0000

Swerve drive is one of the most flexible and rewarding drivetrain systems in FRC. It allows your robot to move in any direction — forward, sideways, diagonally — while keeping its orientation fixed or rotating independently. That control comes at the cost of complexity: four independently steered modules, each with its own motor pair, encoder, and PID logic.

In this post, we’ll walk through the foundation of a swerve module implementation in WPILib using CTRE’s Phoenix 6 API. By the end, you should understand not only how to code a swerve module, but why each piece matters. This article is written both for rookie programmers and experienced teams who want a clean, modular reference.

The Idea Behind Swerve

A traditional tank drive uses two sides of motors: one for the left, one for the right. To turn, one side spins faster than the other. This works well, but it means your robot can’t move sideways without turning first.

Swerve drive changes that completely. Instead of linking wheels in pairs, each wheel (or module) can rotate independently to face any direction and drive at any speed.

So what does that enable?

The robot can move in any direction instantly — forwards, sideways, diagonally.
It can rotate and translate at the same time, something impossible in tank drive.
It makes autonomous paths smoother and more efficient, since motion is continuous rather than segmented.

Mathematically, this is made possible by vector addition. Each wheel’s motion contributes a velocity vector. By combining all four vectors, the robot can produce any movement it wants — translation, rotation, or both simultaneously.

Each swerve module contains the following:

Turning motor
Driving motor
External encoder

It makes a movement like this possible:

Screen recorded from PathPlanner GUI

Defining Constants

Before writing any logic, we define our constants. These govern tuning parameters, motor calibration, and physical conversions. Keeping them centralized makes it easier to iterate later.

public class Constants {
    public static final double kPModuleTurningController = 0.5;
    public static final double kPModuleDriveController = 0;

    public static final double kMaxSpeedMetersPerSecond = 4.0;
    // TODO: 'EncoderDistancePerPulse' should be calculated based on the gearing and wheel diameter
    public static final double kDriveEncoderDistancePerPulse = 0.0011265396; 

    public static final String CAN_BUS_NAME = "CANivore";
}

kPModuleTurningController: Controls how aggressively the module turns toward its target angle.

kPModuleDriveController: Starts at zero; increase later when tuning drive responsiveness.

The kDriveEncoderDistancePerPulse constant translates motor encoder readings into meters or inches traveled, you can change the units you use by changing this constant too — just try to keep everything consistent. You’ll need to calculate this using your wheel diameter and gear reduction.

Finally, specifying the CAN bus name (“CANivore” in this example) helps WPILib locate your devices if you use multiple buses. If you are not using any additional CAN bus and directly connect it to roborio you don’t need this constant.

Constructing the Swerve Module

Now we move into the SwerveModule class, which is what we will use for the rest of the tutorial. There are 4 swerve modules in each robot, so we wanted to have a unified way of controlling these motors. SwerveModule class allows just that.

Here is the field of the class where we initialize our core motors and controllers:

public class SwerveModule {
  private final TalonFX m_driveMotor;
  private final TalonFX m_turningMotor;
  private final AnalogInput m_turningEncoderInput;

  private double turningMotorOffsetRadians;
  private double m_driveMotorGain;

  private final PIDController m_drivePIDController =
      new PIDController(Constants.kPModuleDriveController, 0, 0);
  private final PIDController m_turningPIDController =
      new PIDController(Constants.kPModuleTurningController, 0, 0.0001);
}

We first set our two motors — one for forward/backward and one for turning. In our case, these are TalonFX, but it is also possible to use SparkMax or other motors by changing some of the code. AnalogInput is used as the encoder; it is an external encoder, not the built-in encoder — more on that later in the post.

Then the turningMotorOffsetRadians and m_driveMotorGain are both values that need to be tuned to actually make the front of the robot front — eg, the 0 degrees of the swerve module might be facing some diagonal direction, so we want to add an offset to zero it to the direction that we desire.

PIDController for driving is more about improving accuracy and having a smoother drive; however, it is not required. On the other hand, the PIDConstroller for turning is something you need to use and fine-tune to get better results in rotation, which would significantly impact the speed of the robot.

Initialization and Setup

Inside the constructor, we initialize hardware and configure basic parameters:

public SwerveModule(
      int driveMotorChannel,
      int turningMotorChannel,
      int analogEncoderPort,
      double turningMotorOffsetRadians,
      double driveMotorGain
      ) {

    m_driveMotor = new TalonFX(driveMotorChannel, new CANBus(Constants.CAN_BUS_NAME));
    m_turningMotor = new TalonFX(turningMotorChannel,  new CANBus(Constants.CAN_BUS_NAME));

    m_driveMotor.setNeutralMode(NeutralModeValue.Brake);
    m_turningMotor.setNeutralMode(NeutralModeValue.Brake);

    this.turningMotorOffsetRadians = turningMotorOffsetRadians;

    m_driveMotorGain = driveMotorGain;

    m_turningEncoderInput = new AnalogInput(analogEncoderPort);

    m_turningPIDController.enableContinuousInput(-Math.PI, Math.PI);
}

We start off by initializing our two motors — again, you may not need the second parameter if you are directly connecting the motors to RoboRio.

We set the mode of both motors to Brake as we want to be able to quickly change direction and move.

We set the tuning variables to the parameters. And initialize the encoder input with the given port.

Why enableContinuousInput() Matters

A PID controller normally drives the error between the current and target values. Without continuous input, going from 0° to 360° would make the motor rotate a full revolution — even though those angles are equivalent.

By calling:

m_turningPIDController.enableContinuousInput(-Math.PI, Math.PI);

We tell the controller that -π and π represent the same point, allowing it to take the shortest path between two angles.

Left is how the PID views the value before continuous input, and right is how it views the values after continuous input.

Note: WPILib’s SwerveModuleState also uses radians, so keeping everything in radians avoids unnecessary conversions and rounding errors.

Getting the Module’s State

Before commanding motion, you need a way to know what each module is doing right now — its current wheel angle and drive velocity. That’s where the following helper methods come in:

public SwerveModuleState getState() {
    return new SwerveModuleState(
        m_driveMotor.getVelocity().getValueAsDouble(),
        new Rotation2d(getTurningEncoderRadians())
    );
}

public SwerveModulePosition getPosition() {
    return new SwerveModulePosition(
        m_driveMotor.getPosition().getValueAsDouble() * Constants.kDriveEncoderDistancePerPulse,
        new Rotation2d(getTurningEncoderRadians())
    );
}

getState() returns the instantaneous velocity and orientation of the wheel — this is what the kinematics class uses to estimate robot motion in real time.
getPosition() reports the total distance traveled and current orientation, which odometry uses for tracking the robot’s pose across the field.

See how both of them use getTurningEncoderRadians() which converts the analog voltage from the encoder into a meaningful angle:

public double getTurningEncoderRadians(){
    double angle = (1.0 - (m_turningEncoderInput.getVoltage()/RobotController.getVoltage5V())) * 2.0 * Math.PI + turningMotorOffsetRadians;
    angle %= 2.0 * Math.PI;
    if (angle < 0.0) {
        angle += 2.0 * Math.PI;
    }

    return angle;
}

To summarize, the encoder returns a value — in volts — between 0V and 5V. We can use this to map out a full rotation, as there is a linear relationship between encoder value and the angle. We can divide this encoder value by 5V to get a range 0–1, and that would correspond to 0–2pi rad. So we just multiply it by 2pi and add turningMotorOffsetRadians, depending on the front of the robot and the zero position of the encoder.

An important note here is that subtracting from 1 in the equation depends on the placement of the encoder, so you may want to see if the change in angle makes sense and if it is reversed, just remove “1 -”.

Commanding the Module — `setDesiredState()`

This is the core function of your SwerveModule class. It takes in a target velocity and angle (from WPILib’s SwerveModuleState) and drives the motors to achieve that.

public void setDesiredState(SwerveModuleState desiredState) {
    SwerveModuleState state = desiredState;

    // Prevent jittering at very low speeds
    if (Math.abs(state.speedMetersPerSecond) < 0.001) {
        stop();
        return;
    }

    state.optimize(new Rotation2d(getTurningEncoderRadians()));

    final double driveOutput = m_drivePIDController.calculate(
        m_driveMotor.getVelocity().getValueAsDouble(),
        state.speedMetersPerSecond
    );

    final double driveFeedForward = state.speedMetersPerSecond / Constants.kMaxSpeedMetersPerSecond;

    final double turnOutput = m_turningPIDController.calculate(
        getTurningEncoderRadians(),
        state.angle.getRadians()
    );

    m_driveMotor.set(
        MathUtil.clamp((driveOutput + driveFeedForward) * m_driveMotorGain, -1.0, 1.0)
    );
    m_turningMotor.set(turnOutput);
}

Let’s unpack this:

Preventing Jitter

When the desired speed is extremely small (less than 0.1% of full power), the module shouldn’t bother rotating to match a new angle. That would only cause the wheel to twitch in place.

So we check:

if (Math.abs(state.speedMetersPerSecond) < 0.001) {
    stop();
    return;
}

This line saves wear on your steering motor and reduces noise when the robot is idle.

Optimizing the Wheel Angle

state.optimize(new Rotation2d(getTurningEncoderRadians()));

SwerveModuleState.optimize() ensures the module takes the shortest way to reach the target direction. For example, instead of rotating 270°, it might flip the wheel 90° and reverse drive direction — same motion, faster response.

See the illustration below:

Illustration on the left rotates more compared to the right illustration to be in the same position.

Drive Output Calculation

The drive motor’s control has two parts:

First, PID drives the motor to the target speed by using the previously defined proportional, integral, and derivative values. (See more on how PID works):

m_drivePIDController.calculate(currentVelocity, targetVelocity)

Then we use feedforward to keep the wheel moving at the same velocity:

state.speedMetersPerSecond / Constants.kMaxSpeedMetersPerSecond

Both are combined, scaled by m_driveMotorGain, and clamped between -1 and 1 (full reverse to full forward).

Turning Output Calculation

Turning is entirely handled by the PID controller:

final double turnOutput =
    m_turningPIDController.calculate(getTurningEncoderRadians(), state.angle.getRadians());

This minimizes angular error between the current and target direction. Because we previously enabled continuous input, it always takes the shortest path across the ±π boundary.

Setting Motor Outputs

Finally, we command the motors:

m_driveMotor.set(
        MathUtil.clamp(
            (driveOutput + driveFeedForward) * m_driveMotorGain,
             -1.0, // min -100%
             1.0) // max +100%
    );
    m_turningMotor.set(turnOutput);

At this point, each module runs semi-independently: it continuously reads its encoder, calculates new outputs, and steers to the desired state.

Putting It All Together

With SwerveModule complete, you can now instantiate four of them in a drivetrain subsystem:

SwerveModule frontLeft = new SwerveModule(...);
SwerveModule frontRight = new SwerveModule(...);
SwerveModule backLeft = new SwerveModule(...);
SwerveModule backRight = new SwerveModule(...);

Then, using SwerveDriveKinematics, combine their states into a robot-level motion command. WPILib’s kinematics and odometry classes handle the math — your SwerveModule executes per-wheel control.

Next Steps:

After this point, you need to perform the calculations to enable these separate modules to work together in moving the robot. This could be done in a wide variety of ways, depending on how you want to organize everything, but just make sure to keep your units consistent.

You can watch this video to go deeper into swerve drive and how to code it.

Here is the complete code of the SwerveModule:

GitHub - SuleymanSade/SwerveDriveBase

I write about learning AI by building real tools, not just tutorials.

I write more tutorials, personal thoughts and development stories on my blogs you can:

📰 Read more of my posts on Medium
💬 Let’s connect on LinkedIn

Thanks for reading — let me know if you’d like to collaborate on projects similar to these or have any questions.

When a For Loop Powers Your Stock Backtester - Devlog

Suleyman Sade — Wed, 10 Sep 2025 03:40:31 +0000

Yeah, you heard that right.

This is part 6 of my Building Stocksimpy series, where I build a light-weight Python backtesting library, sharing every step along the way.

In the last post, I explained why I created Portfolio class: to keep everything organised and divide the load between classes. Portfolio supports the main backtesting loop, which is what I’ll dive into today.

Strategy

Backtester class is simple by design, and it should be. The strategy —deciding whether to buy or sell — is provided when the class is initialized. My initial thought was to have strategy as a simple function returning buy, sell, or hold. And that's the way it works in the code right now.

However, some strategies may require multiple calculations and calling a bunch of different functions to calculate whether it is worth selling or not. So I might pivot to allowing either a function or a class. And if it is a class, I can decide on a signal_generator() that can still be used to generate the signal.

This approach offers more flexibility, but since I am keeping things relatively lightweight, I will revisit this in the future.

Main Loop

The core loop is literally a simple for loop iterating over the length of the data. At first, I worried about performance — would processing large datasets take forever? Running 5–10 years of daily data took about 2 minutes on my machine, which is acceptable for a fully Python implementation.

High-performance backtesting libraries often rely on C/C++ and create Python bindings. So I wasn’t expecting a performance similar to those top libraries, but still, it shouldn’t take hours to complete.

But something I didn’t look too much into was Pandas built-in functions. I could’ve used strategy to precompute signals beforehand and storing them in a Pandas.Series. Then I could run a for loop for the dates where there is a trade. This would have been much more efficient, and I might implement it in the future.

Fixed vs. Dynamic Backtesting

I’ve built two run_backtest() functions to run it. Why? I wanted to keep things simple while also offering flexibility. I wanted to allow users to just trade a fix amount. But then I realised this can get very limiting, even for simple testing purposes.

I wanted to write a strategy that sells half of the owned stock tied to a logic, but this was not possible by only getting a signal. So I created run_backtest_dynamic() to allow returning how many stocks to buy, as well as a run_backtest_fixed() to still allow for a custom amount of money per trade.

What’s Next

I’ve considered adding features like running multiple strategies simultaneously and more advanced metrics. One comment reminded me of risk-adjusted performance measures — without metrics like Sharpe ratio or drawdowns, Stocksimpy is just a toy. Implementing these will be the focus of the next post.

Visualization and documentation cleanup are still on the roadmap, but risk-adjusted calculations take priority. Stay tuned.

Please check out Stocksimpy Github and give any feedback that you see appropriate. I hope this project helps out instead of wrestling with complex libraries. See you in the next post 👋:

GitHub - SuleymanSade/StockSimPy: A lightweight Python library for backtesting stock strategies

Also check out my socials and let's connect:

🧠 Follow me on Twitter / X
🔷 I’m now on Bluesky
📰 Or read more of my posts on Medium
💬 Let’s connect on LinkedIn

Inside the Portfolio: How Stocksimpy Tracks Trades and Value

Suleyman Sade — Wed, 03 Sep 2025 00:35:58 +0000

From Cash to Stocks: Watch Your Portfolio in Action

This is part 5 of my “Building Stocksimpy” series, where I’m building a lightweight Python stock backtesting library from zero.

In the last post, I explained why I want Stocksimpy to stay simple: each class should have a clear purpose, instead of dumping everything in one giant backtester class.

This was why I had created StockData earlier to manage the stock price history. But only knowing the prices of stocks doesn’t get you far — I needed a way to track available cash, trades, and holdings. That’s where the Portfolio comes in.

Why a Portfolio Class?

Indicators are useless without an account keeping track of your trades — so I built the Portfolio.

Portfolio is essentially the accountant, keeping track of all the money flow. Sure, you could track this with a data frame inside the backtesting loop. So why use Portfolio? There is a principle in software development called:

Don’t Repeat Yourself (DRY)

Coding consists of objects, functions, classes, and many more. Why repeat yourself again and again when you could just call the same function? This is the main reason why I wanted a centralized Portfolio class.

And not only that, having a Portfolio class allowed me to separate cash flow and actually run the backtesting logic, so instead of trying to push everything together, I could separate different tasks in the code. Otherwise, I would be rewriting buy/sell logic over and over again, and imagine having to change a minor error in that code — I am leaving the rest to your imagination.

Three Core Responsibilities

What comes to your mind when I say Portfolio — in trading: total money, stocks, and other equities. That is exactly what Portfolio does, additionally, anything that is related to the flow and recording of that money/holdings.

Storing cash and holdings

At its core, Portfolio keeps track of your available cash (self.cash) and all your holdings (self.holdings). This may sound simple, but having a single place for this information prevents mistakes and makes the code cleaner.

Buy and sell operations

I didn’t want the backtester loop to have direct access to the cash and holdings. So I decided the second responsibility should be buy/sell operations. Now buying/selling would require Portfolio knowing the current price of the stock, meaning it needs StockData which was something I was against doing, as Portfolio had to be used standalone.

Solution? I just added price parameter to exec_trade() so that this value could be provided by the backtesting loop or the user directly. And the direct access and alteration are done by exec_trade().

Tracking history

Porfolio may seem complete by now, but there is a 3rd critical responsibility: tracking history. User needs to be able to access the portfolio changes when the simulation buys/sells stock, and the total valuation. This was fairly easy to implement by _log_trade() recording every trade in self.trade_log.

Here is an example run of how it works:

from portfolio import Portfolio

# Start out with $10,000
myportfolio = Portfolio(initial_cap = 10_000)

# Buy 10 NVDA stocks at $170 per stock
myportfolio.exec_trade(
  symbol='NVDA',
  trade_type='Buy',
  price=170,
  shares=10,
  date=current_date
)

An interesting bug I encountered: Python won’t let you increment a value for a key that doesn’t exist yet in a dictionary. The solution? Use defaultdict(int) from Python’s collections module. This automatically initializes new keys to 0, solving the problem neatly.

Future?

Portfolio is designed to act independently, so it can be used in custom backtesting loops. It already handles multiple stocks without issue, although the first version of Backtester won’t fully leverage them yet.

Next up: Backtesting logic.

What else?

If there are any suggestions or improvements you want for Stocksimpy. Please let me know through either my socials or by directly commenting on them. I want this library to be useful to others, and anyone who is just starting out with quant finance.

Thanks for reading — hope you enjoyed. Before you leave, please:

⭐ Star stocksimpy on Github
🧠 Follow me on Twitter / X
🔷 I’m now on Bluesky
📰 Or read more of my posts on Medium
💬 Let’s connect on LinkedIn

A change in vision | Building Stocksimpy (Devlog 4)

Suleyman Sade — Wed, 27 Aug 2025 19:19:52 +0000

Imagine being able to test your strategy in less than 10 lines of Python code, rather than spending hours with other libraries. This is what will make `Stocksimpy` useful.

This is the 4th (technically 5th) post in my devlog series on building Stocksimpy, a lightweight Python backtesting library. Read the rest of the series here.

I’ve been developing Stocksimpy for about a month now. Along the way, I learned a lot, from how to properly document a library to how to write reusable code. Those were my original goals: I wanted to learn. But if I’m honest, learning for myself isn’t enough — I want to build something actually useful for others too.

This shift made me revisit the origin of Stocksimpy.

The idea came when I was building a simple stock prediction script. I could generate numbers and plots, but all I saw was just a bunch of data flowing and no real sense of whether the model was “working.” Was it actually successful, or just noise?

Naturally, I looked for existing Python backtesting tools. What I found was overwhelming: libraries that required setting up accounts, managing APIs, and losing myself among lines of configuration. These are powerful tools, but for quick experimentation, they felt like overkill. I didn’t want complexity — I wanted something lightweight, intuitive, and well-documented.

That’s how the idea Stocksimpy was born. A Python library designed to be simple enough for a weekend experiment, yet structured enough to scale as strategies get more advanced. From the start, I chose to build in public, updating the GitHub repo as the project grew.

But recently, I realised I was just re-implementing the same indicator logic that major libraries like TA-Lib already provide. That was never the purpose of Stocksimpy. So I am doing some reconfiguration on the skeleton of the library. Here is what it will look like:

indicators.py: Contains some simple common indicators for quick testing and development.
StockData: Holds the Pandas data frame related to stock data.
Portfolio: Contains the history of buy/sell, currently held stocks, and manages buy/sell operations.
Backtester: Where the user inputs their strategy and a StockData to test, where the main loop occurs.
Visualize: Visualizes the result and change of the total amount.

I finished coding a working draft for the first three, and will post a blog post about Portfolio soon.

As these are the main classes of my library, I am aiming for a workflow similar to the following:

def strategy():
  # This is where the user builds their own strategy
  skip

from stocksimpy import StockData, Visualize, Backtester # 1

# Import the data, supports SQLite, pd.dataframe, dict, yfinance, and more
data = StockData(df) # 2

# Create a Backtester object with $100,000 initial money
backtest = Backtester(data, strategy, initial_cap=100000) # 3

# Runs it
backtest.run_backtest() # 4

# Visualizes the cap change
Visualize.visualize(backtest) # 5

So if this works as I expected, with only 5 lines of code it is possible to run a backtest for a strategy.

If there is anything you want me to add, or any suggestions, please reach out to me on my socials, or comment it below 👇. It really helps with improving the library.

If you would like to support me:

⭐ Star stocksimpy on Github
🧠 Follow me on Twitter / X
🔷 I’m now on Bluesky
📰 Or read more of my posts on Medium
💬 Let’s connect on LinkedIn

Thanks for reading — let me know what else you want me to add.

Creating Stock Data | building stocksimpy 3

Suleyman Sade — Wed, 20 Aug 2025 17:55:25 +0000

StockSimPy is a lightweight Python library for simple stock backtesting. The goal is to understand Pandas, experiment with stock strategies better, and create an easy-to-use alternative to more complex backtesting tools. This is part 3 of the series where I build this library in public.

After finishing basic indicator calculation functions, I needed a way to keep track of all the stock information in an organised, reusable format. That’s where the StockData comes in — it acts as a container for everything you’ll need in backtesting or simulation.

I initially thought it should be easy to code as it just needed to keep the information and require some simple import and export, but I was quite wrong. Turns out working with data can be messy.

Data Validation

When importing stock data, you can’t assume the columns are always consistent. Strategies require the use of different features, but some fields are essential:

The tricky path — though — is naming conventions. What do I mean?

Let's take “Open” as an example; it could show up as “OPEN”, “open”, “OpeN”, “open_price”, “OpenPrice”, “openPrice”, and many other wild naming styles.

Lowercasing handles some cases, but what about the ones with “price” in the name? Then I thought — I could easily search for the substring “open” in the whole word. This covers all the cases I mentioned above, but if open is named something else entirely, it wouldn’t work.

A more comprehensive approach might be to create a full-blown synonym-matching system. But that might be overkill for now. Still, I might add it as a feature in the future if somebody requests it.

Data Import

The most important feature of StockData is importing data—without that, it’s just an empty shell.

I was quite skeptical about creating these import functions at first. I considered leaving import up to the user — just pass in a Pandas DataFrame — but having built-in loaders felt more convenient. So far, StockData supports imports from:

SQLite
CSV
Excel
Pandas DataFrame
Python dictionary
JSON

(This process felt quite repetitive as I was just using built-in pandas functions or just straight-up copying documentation.)

To simplify things, I added anauto_loader() function that picks the correct import based on the file extension of source parameter. I used **kwargs so users can pass in additional parameters.

On top of that, StockData integrates directly with yfinance (optional dependency). This allows fetching live stock data for a given ticker and date range, making it much more practical.

For testing purposes, there’s also a generate_mock_data() function. It isn’t designed for real backtesting but is useful for experimenting with new features.

Data Export

Here is a question: why export data you already imported? Two reasons:

Users might want to inspect or clean their data after transformations.
I will soon integrate the indicator functions from earlier posts, with StockData so exporting results will be handy.

Export currently supports all the same formats mentioned in import, plus SQL. There is also a flexible to_custom() function that lets you define your own export method.

It was such a twist, this step turned out to be more about data flexibility rather than really "storing data." With StockData in place, stocksimpy now has a solid foundation for testing.

If you want to use this library in the future, or have any ideas that I could add, go for it. Ask me in comments, connect with me on socials. I want to make this project something useful.

Follow the rest of the series, watch me build in public.

🌟Star this on GitHub
🧠 Follow me on Twitter / X
🔷 I’m now on Bluesky
📰 Or read more of my posts here on Medium
💬 Let’s connect on LinkedIn

Thanks for reading.

What Losing a Hackathon Taught Me About Code — and Myself

Suleyman Sade — Wed, 13 Aug 2025 08:54:56 +0000

A self-reflection on my past project — DiaGuide — and what I learned about “good code”

I thought I had something good. DiaGuide — a diabetes risk prediction app I built in under 48 hours — was working. The ML model ran fast, the precision was acceptable, and the website was clean. I even added subtitles to the demo, just to cover the “accessibility” criteria.

I submitted it thinking, This could win. I imagined the approval from the judges, getting that DevPost badge, and seeing a certificate with my name on it. Every notification made me reach for my phone.

Then the winners were announced. I wasn’t on the list. I checked again, and there was nothing.

That loss hurt more than I expected. This was supposed to be a simple project that I built over the weekend for fun. Then I looked back at my project, and I was confronted by some hard truths about design, collaboration, and what “good code” actually means.

Design

The moment I opened the web page, I was greeted by a generic form design with nothing unique to offer — just a simple toggle select. Since I didn’t have much prior experience with UX/UI design or building interfaces, I used Streamlit because it integrated well with the rest of my Python ML code. However, compared to the winners’ web pages — visually polished and built with React — mine felt way too simple.

I knew this would be an issue before I even started coding, so I tried to make things more interesting by showing the form questions one at a time. But it didn’t work as I expected. There was a bug where, after I clicked “next,” the next question popped up beneath the previous one, and the old question wouldn’t disappear until I selected an answer for the new one. I decided to turn this bug into a feature, because it seemed nice at the time. But that was a mistake.

Instead of making my form page feel more unique, it just made it look buggy. In some cases, the previous question would suddenly disappear in a jarring way; in others, the new question would collapse to the top, forcing the user to move the cursor all the way up to continue.

(Here is how annoying it is: — Screen recorded by author)

Collaboration

Here’s a harsh truth I learned about building: one person cannot do everything perfectly. I soloed the whole project and did everything from front-end to ML models; I didn’t have time to perfect either, so the result felt rather incomplete.

I learned that it is important to build in teams where everyone specializes in a certain aspect of code — one person builds the ML model, another the front-end, another the back-end, etc. That way, it’s much easier to build, and the result feels complete and functional.

When I was building solo, I spent half my time switching hats — ML engineer, front-end developer, bug fixer, sysadmin. Every time I focused on one aspect, I had to completely switch gears and adapt for the other. This mental gear-shifting slowed me down significantly.

But this doesn’t happen in a team; one person can work on polishing the UI while the other fine-tunes the ML model. The pieces come together faster, and you’re not stuck in “fix everything yourself” mode. It’s less stressful, and the result feels polished.

Another important aspect of being in a team is continuous feedback. I believe one of the main reasons my project fell short is because I didn’t get feedback about how terrible my UI was. I’ll admit, it was unbearable. And I can definitely see that now. But when I was building it, it seemed perfectly fine and somewhat “original.”

The excitement of building something and the stress of trying to finish on time made me blind to my project’s weaknesses. That’s why I wish I had worked with someone else. (I actually invited somebody, but they had something come up at the last minute.)

I’ve talked all about the benefits of being in a team, but is being a solo builder that terrible? If you don’t like constantly giving updates, trying to glue every piece together, or spending hours convincing teammates to add certain features, then being solo might not be so bad.

Being a solo developer can speed up some parts of the development since you don’t lose time communicating or trying to piece everything together.

But I believe the time saved by being in a team is much more significant than the time saved by building solo.

What “Good Code” Really Means

After losing, I went back through my code and realized it was full of little details that I loved but the user would never see. I spent quite a bit of time making all the questions line up perfectly with one another, but that didn’t benefit the user at all.

I remember endlessly pressing Tab and arrow keys to fix indentation issues. But none of that was necessary.

I’ve always loved coding with great structure — everything lined up perfectly, every variable name making sense. While that’s nice for developers, including myself, it doesn’t add anything for the user.

The user doesn’t see my elegantly aligned lists or the clever Python trick I slipped in. They only care about what’s in front of them — because that’s actually what matters.

When I think about what “good code” means, I ask myself: Why do we code? What’s the purpose? It’s to build a product, maybe a service — not just to produce clean, well-organized code. Good code isn’t the end goal. It’s a tool to deliver something people find valuable.

It doesn’t make sense to complicate your code when it has minimal effect on the user’s end. I spent a significant amount of time trying to make my form viewer “original” while I could have spent all that time trying to fix the buggy transition between questions.

Looking back, that was the biggest shift in my mindset; good code isn’t about making the developer happy, it is about making the user’s life easier. I could use all the — so called — best tools in the world but if it doesn’t make a difference for the user, they are a waste of time.

The realization stung because it meant I spent my 48 hours worrying about the wrong things instead of what really matters. But it also stuck with me — and weeks later, DiaGuide still mattered to someone.

One day I got a message on my Dev.to post explaining DiaGuide. It was from someone with type 2 diabetes. They wrote that tools like DiaGuide can help people catch risk early and take action — and that it could encourage someone to take action.

It wasn’t a certificate or a DevPost badge, but it felt better. I might have lost the hackathon, but I had built something that actually mattered to someone. And that’s the real reason it’s worth putting time and effort into building tools, websites, and anything else — because they can make a difference.

I write about learning AI by building real tools, not just tutorials.

⭐ Star this on Github
🧠 Follow me on Twitter / X
🔷 I’m now on Bluesky
📰 Or read more of my posts on Medium
💬 Let’s connect on LinkedIn

Thanks for reading — let me know about your experiences with hackathons!

🐍 Top Python Libraries to Supercharge Your Productivity

Suleyman Sade — Sat, 02 Aug 2025 08:41:50 +0000

In this blog post, I will cover some of the best libraries to manage documentation, dependencies, testing, formatting, and much more.

As Python developers, we juggle a variety of tools — from testing frameworks to formatters, documentation tools to dependency managers — all in the name of productivity. But not all tools are created equal.

In this post, I’ll walk you through some of the most effective Python libraries to help you write cleaner code, avoid technical debt, and speed up your development workflow.

Testing Tools/Libraries

Testing might feel like a roadblock when you just want to ship, but it’s essential for building maintainable, bug‑resistant code. These tools make testing faster and more intuitive:

1) Pytest:

Pytest is the de facto standard for testing in Python — easy to start with, yet powerful enough for advanced use cases. It lets you assert function outputs, check for exceptions, and even parametrize tests for broader coverage.

Basic assertion:

def add(x, y):
    return x + y

def test_add():
    assert add(2, 3) == 5

Testing for exceptions:

import pytest

def divide(x, y):
  if y==0:
    raise ValueError("Cannot divide by zero")
  return x/y

def test_divide():
  with pytest.raises(ValueError):
    divide(10, 0)

Pytest also supports:

Parametrized testing with @pytest.mark.parametrize
Fixtures for reusable setup
Plugins for test coverage, mocking, and more

Documentation

Documentation may feel like a distraction from “real coding,” but it is essential if you want your project to be usable, maintainable, or collaborative. Good documentation is the cornerstone for open‑source projects as it allows for other devs to easily understand why, how, and what you wrote in your code.

Documentation not only helps others but also helps you by acting like a second brain when revisiting old code or reminding you why you made certain choices in your code.

Here are two widely used Python tools for building documentation:

Sphinx

Sphinx is a powerful tool originally built for Python’s own documentation. It uses reStructuredText (or Markdown with extensions) and supports automatic generation of API docs from your code’s docstrings. This means you don’t have to worry about updating your documentation when you change a docstring in your code. It automatically updates when you build, so it cuts the worry of switching between editing code and documentation.

Why use it:

Supports themes like Read the Docs
Integrates with Autodoc to generate docs from code
Great for large projects or libraries
Automates more of your workflow

If you want to get started you can read the my following blog post: Setting Proper Documentation With Sphinx Docs

MKDocs

MKDocs is a simpler alternative using a Markdown-based static site generator designed for project documentation. It’s easier to configure than Sphinx and has great theming support.

Why use it:

Easy to write in Markdown
Fast to set up and deploy
Ideal for smaller projects, developer tools, or internal docs.

MKDocs vs. Sphinx: Which Should You Use?

Use Sphinx if:

You are building a big project
Want to automate creating documentation
Okay with spending time configuring Sphinx

Use MkDocs if:

You want something quick, clean, and Markdown‑based
Building a small‑scale project
Don’t want to spend too much time on documentation

In short:

Sphinx = More powerful, but more complex
MkDocs = Simpler, but less flexible for auto‑generating docs

Code Formatting

Code style shouldn’t be a matter of debate in a project; you don’t want to spend all your time formatting your code when you can build new features — that's why formatter tools are a necessary piece of your workflow.

Formatter and linter tools help you enforce consistent style, catch bugs early, and reduce time wasted on code review nitpicks.

Black

Black is a code formatter that always formats your code to a consistent style — no configuration needed. This removes the need for making specific stylistic choices, potentially saving you both time and brain power.

But there is a drawback: you can’t tweak the style — you either accept it or don’t use it. This could be a huge problem when you already have a codebase formatted differently from “Blackened” code.

Usage:

black main.py

Ruff

Ruff is a fast Python linter and formatter written in Rust. If you have a big codebase that requires blazing‑fast formatting, this is your option.

Unlike Black, Ruff is highly configurable with compatibility for many common linter rule sets. It can replace multiple tools as it combines linting and formatting in one tool.

Usage:

ruff check project/
ruff format project/

Flake8

Flake8 is a classic Python linter that checks for PEP8 compliance and potential bugs. It is widely adopted in the industry, with many plugins to make it suitable for your needs.

It integrates well with other tools and IDEs; however, it is slower than Ruff and requires multiple plugins to match modern standards.

Which One Should You Use?

Use Black if:

You want a simple, consistent formatter
Don’t want to spend much time worrying about style

Use Ruff if:

You want an all‑in‑one linter/formatter
Require high customizability and speed

Use Flake8 if:

You're working in a legacy codebase or team dependent on it
Need integration with specific IDE tooling

Type Checking

Python is a dynamic programming language, meaning it doesn’t require you to choose certain types for your variables. This offers great flexibility but comes with a major caveat: errors.

Static type checking helps catch bugs before runtime, improves IDE support, and clarifies intent, as well as making your code more readable.

Mypy

Mypy is a static type checker that works with Python’s built-in type hints to validate your code before execution.

Basic Example:

def greet(name: str) -> str:
    return f"Hello, {name}"

def square(n: int) -> int:
    return n * n

Now, if you accidentally call square("4"), Mypy will raise an error.

Usage:

mypy main.py

Dependency Management

We discussed several tools that you can already use, and as your project scales, the number of dependencies will scale tremendously. Managing all these dependencies is crucial for reproducibility and collaboration. Here are two tools to make this seemingly annoying process easier and more consistent than using plain pip and venv.

Pipenv

Pipenv combines pip and virtualenv into a unified workflow. It generates Pipfile and Pipfile.lock to keep track of your dependencies and manage your virtual environment.

These tools simplify setting up your environment as well as your dependencies, and the lockfiles ensure reproducible builds, so clients don’t face unexpected issues. However, dependency resolution can be slow, and development activity has slowed recently.

Usage:

pipenv install requests
pipenv shell

Poetry

Poetry is a more modern alternative to manage your venvs, dependencies, and Python packaging — all in one place.

It uses the new pyproject.toml standard, is faster, deterministic in dependency resolution, and easier to publish to PyPI. That said, it can be harder to set up and less beginner-friendly.

Usage:

poetry init
poetry add pandas
poetry shell

Which One Should You Use?

Pipenv if you're starting small or need something beginner-friendly
Poetry if you want performance, modern workflows, and are packaging or scaling your project

Conclusion: Choose Tools That Scale With You

Productivity in Python isn’t about piling on tools, chasing hype, or pouring hours into complex workflows when that time could go into code.

It’s about choosing tools that align with your workflow, team, and project’s scale. Sometimes the smartest choice is not adding another dependency.

If you're just getting started, begin with Black, Pytest, and Pipenv. You don’t need the most advanced tools right away.

The ecosystem is rich—but you don’t need everything. Adopt tools incrementally.

The best tooling isn’t the most powerful — it’s the one that removes friction without getting in your way

I write about learning AI by building real tools, not just tutorials.

🧠 Follow me on Twitter / X
🔷 I’m now on Bluesky
📰 Or read more of my posts on Medium
💬 Let’s connect on LinkedIn

Thanks for reading — let me know which one of these you would use/ have used.

From SMA to TEMA: Coding Technical Indicators in Python — Building stocksimpy 2

Suleyman Sade — Sat, 26 Jul 2025 06:44:31 +0000

Most of the stock back-testing tools and libraries I've seen are either too complex for beginners or have a steep learning curve. So I decided to build my own Python library from scratch called stocksimpy which aims to be a light-weight and well-documented alternative to what is out there.

One of my primary goals with this series is to learn how Python libraries work, as well as to improve my skills in Pandas and NumPy. And create something that could grow into a real tool for others to use.

In the process, I ended up implementing over 10 indicators from scratch.

Here’s how I approached, what I learned, and how you can do the same:

Why Build Indicators From Scratch?

This is a valid question. I also asked myself this when I reached about 300 lines of code. But then I realised that when I was coding these indicators, I was learning how they work. This hit me when suddenly the equation for TEMA calculation appeared in my eyes:

(3 * EMA_1) — (3*EMA_2) + EMA_3

This was enough to prove that I was learning something, and I was also getting better at using Pandas.

This was also my Python library that I built from zero, so I wanted to have total control over what to include and how to organize them.
Also, something about Python libraries is that you want to keep dependencies to a minimum, and I already had to use NumPy and Pandas , so adding another packed dependency might have been too much — which I tried to avoid.

Deep Dive Into Common Indicators

Overview of indicators implemented so far:

Moving Averages: SMA, EMA, DEMA, TEMA, HMA
Momentum Indicators: RSI, MACD, Wilder’s MACD, HMA-MACD, TEMA-MACD
Smoothing: Wilder’s Smoothing

Now let's break down each one of them as well as their implementations:

Simple Moving Average (SMA)

SMA is just the average of a fixed number of consecutive values in a series. Let’s break it down:

data_series = [1, 3, 4, 6, 8]

window = 3

Now, calculate the average of each group of consecutive numbers:

The first two numbers don’t have enough data before them to form a full window, so we assign NaN for them.

Next values are:

(1 + 3 + 4)/3 = 2.67
(3 + 4 + 6)/3 = 4.33
(4 + 6 + 8)/3 = 6.0

So the result should look like this:

[Nan, Nan, 2.67, 4.33, 6.0]

This could be implemented easily in Python:

def calculate_sma(data_series: pd.Series, window: int):
  return data_series.rolling(window).mean()

In this code, we use .rolling(window) to create a moving window of specified size, and get the average of each using mean().

Weighted Moving Average (WMA)

While SMA gives equal weight to all the values in a given window, we sometimes want to give more weight to recent values to make it more responsive to recent price changes. This is when WMA is used:

The formula is linear:

WMA(n) = (V₀ × n + V₁ × (n−1) + V₂ × (n−2) + … + Vₙ₋₁ × 1) / (n + (n−1) + … + 1)

Where:

V₀ is the most recent value
n is the window size
The denominator is the sum of the weights: n(n + 1)/2

Exponential Moving Average (EMA):

WMA helps with giving some weight, but sometimes you want to be even more responsive to recent changes. This is where we use EMA, which weights exponentially instead of linearly, and also forms the foundation for indicators like MACD.

Calculating EMA is a bit more complicated than the previous two.

To calculate the current EMA value, you need the EMA of the previous day, so it requires a recursive pattern. Here is the equation:

Source: How Is the Exponential Moving Average (EMA) Formula Calculated?

Even though the calculation seems complicated, the code implementation is pretty easy:

def calculate_ema(data_series: pd.Series, window: int) -> pd.Series:
  return data_series.ewm(span=window, adjust=False, min_periods=window).mean()

Here, .ewm() applies the exponential weighting and span=window ensures that it uses the k equation described above. adjust=false makes sure that it uses recursion. And the final .mean() calculates the EMA.

Double Exponential Moving Average (DEMA)

DEMA is designed to reduce the lag that is found in EMA by combining two EMAs into one formula.

Formula is as follows:

DEMA = 2 × EMA1 — EMA2

EMA1: standard EMA
EMA2: EMA of EMA1

Meaning you first find the standard EMA and then find the EMA of EMA, and finish by combining these two EMAs into one.

Why does DEMA reduce lag?

In standard EMA or SMA, sudden changes in value take time to recover — since we are still using the previous values to get the EMA/SMA. For example, in [100, 101, 102, 120, 121, 122] there is a sudden increase from 102 to 120, but when calculating EMA, the first values that are close to 100s are going to bring the average down from 120 to 110ish, which is called lag.

What DEMA does is that it calculates the EMA of EMA so that it lags even further and then subtracts it from the standard EMA times 2, essentially pulling the result forward.

Here is a Python implementation of DEMA using the previous calculate_ema() function:

def calculate_dema(data_series: pd.Series, window: int) -> pd.Series:
  ema1 = calculate_ema(data_series, window)
  ema2 = calculate_ema(ema1, window)

  return (2 * ema1) - ema2

We calculate the ema1 by getting the EMA of data_series and then ema2 by calculating the EMA of ema1. Then we do the calculation and return it — pretty simple.

Triple Exponential Moving Average (TEMA):

TEMA takes the concept behind DEMA one step further by combining 3 EMAs into one, smoother, and even more responsive indicator.

The formula looks slightly complex, but it follows a similar idea:

TEMA = (3 × EMA_1) — (3 × EMA_2) + EMA_3

EMA_1: Standard EMA
EMA_2: EMA of EMA_1
EMA_3: EMA of EMA_3

So, how does this help?

Each layer adds more smoothness — but also more lag.

TEMA corrects for this by amplifying the most recent EMA (3 × EMA_1), which results in 3×lag, subtracting out the additional lag (3 × EMA_2), which is 3xlag - 6xlag = -3lag. Then the final EMA_3 is used to avoid overcompensation: -3lag + 3lag = 0lag — which means no lag.

Here is my Python implementation in stocksimpy :

def calculate_tema(data_series: pd.Series, window: int) -> pd.Series:  
  ema1 = calculate_ema(data_series, window)
  ema2 = calculate_ema(ema1, window)
  ema3 = calculate_ema(ema2, window)

  return (3*ema1) - (3*ema2) + ema3

I think the code is pretty straightforward. It uses calculate_ema() to calculate ema1 , ema2 and ema3 . Then the equation is implemented.

What’s Next?

These moving averages (MA) form the foundation of many powerful technical indicators used in trading and analysis. By building them from scratch, you not only gain a deeper understanding of how they work but also how to improve your skills with Pandas and NumPy .

In the next article in this series, I’ll dive into momentum indicators like RSI, MACD, and some custom variations — showing you how to implement these step-by-step.

I write about learning AI by building real tools, not just tutorials.

🧠 Follow me on Twitter / X
🔷 I’m now on Bluesky
📰 Or read more of my posts here on Medium
💬 Let’s connect on LinkedIn

Here is the GitHub link to stocksimpy which contains all the functions used in this article, and most of the equations:

https://github.com/SuleymanSade/StockSimPy/tree/dev?source=post_page-----16e684091789---------------------------------------

Setting up proper documentation with Sphinx docs — Building stocksimpy 1

Suleyman Sade — Fri, 18 Jul 2025 19:52:49 +0000

Hi there! If you are new to this series, “Building stocksimpy” is a series where I create a new Python library from scratch, documenting every step along the way. The goal of the library is to be a lightweight, open-source, and well-documented alternative to other stock strategy testing libraries.

It’s a journey for me to learn Python, improve my software engineering skills, and explore data science.

Why Set Up Sphinx Docs Now?

One of my main goals with stocksimpy is to keep the codebase beginner-friendly and maintainable. That means having great documentation from day one.

Instead of manually writing Markdown and trying to keep the documentation updated every time I make a small change, I decided to use Sphinx, a powerful tool to auto-generate HTML documentation for Python code’s docstrings.

What is Sphinx?

Sphinx is a documentation generator that pulls information directly from your code, and Sphinx docs automatically detect all of your docstrings in your .py files. Then, it generates an HTML file containing all of your documentation in an organized manner. It is widely used in the Python ecosystem, including major libraries like NumPy, pandas, and scikit-learn.

It might seem like a small help, but in reality, constantly updating your documentation as you build new functions or changing the documentation that you already wrote is hard to maintain. And making all this look good at the same time just becomes a headache. Sphinx does all this for you so you can focus on writing your code.

How to Set up Sphinx?

First, locate the directory that contains your project. Then, to set up Sphinx docs, I would suggest creating a new folder called docs. This helps keep everything organized.

Locate the docs directory, and then if you haven’t downloaded Sphinx before, run the following line(s):

Create Virtual Environment(recommended):

python -m venv venv

Activate the virtual environment

On Windows:

venv\Scripts\activate.bat

On Linux/macOS:

source venv/bin/activate

Install Sphinx

pip install spinx

If you want to, like I did, you can install a popular theme like sphinx_rtd_theme:

pip install sphinx_rtd_theme

Setting up Spinx

To get started, you can run the following line:

sphinx-quickstart

This will ask you the following questions:

Separate source and build directories (y/n): Generally, saying y is a good choice as it keeps your directory cleaner, which is also what I did.
Project name, author, version, release: Fill these in as appropriate. If this is your first release, you could say 0.1.0
autodoc: automatically insert docstrings from modules (y/n) [n]: If you’re documenting Python code and want to automatically pull in docstrings, choose y. This is highly recommended for Python projects.

After answering these questions, Sphinx is going to create a set of files. After that, your docs directory looks something like this:

Configuring conf.py

All the information you just answered is stored in conf.py, and you can edit it as you wish. Here are some things to check: project, copyright, author, version, release.

extensions: This list defines which Sphinx extensions are active. If you chose autodoc during quickstart, it should be there. Here are some others you might want to add:

sphinx.ext.autodoc: for Python docstring
sphinx.ext.napolean: if you use Google or NumPy style docstrings, I will show you an example
sphinx.ext.viewcode: adds links to source code
sphinx.ext.intersphinx: to link to the documentation of other Sphinx projects Here is an example extensions that I used in stocksimpy:

If you also installed the sphinx_rts_theme I mentioned for a more modern look:

html_theme = 'sphinx_rtd_theme'

And finally, at the top of your conf.py you should have the following code:

import os
import sys
sys.path.insert(0, os.path.abspath('LINK_TO_YOUR_CODE')

Fill in LINK_TO_YOUR_CODE wherever your code is located. (Mine is “../../src”)

Add Content

You can write your documentation in reStructuredText(.rst).

index.rst is your main entry point. It contains toctree(table of contents tree) directive to link to other documentation files. Here is an example from my code:

For these references you need to create new .rst files and in my case, I create api.rst file (in source). In your other reference .rst files you can directly bind it to a module, and it documents it for you!

Here is my api.rst:

API Reference
=============

.. automodule:: stocksimpy.data_handler
   :members:

.. automodule:: stocksimpy.indicators
   :members:

data_handler and indicators are the names of my modules inside of my packages (stocksimpy).

Build Your Documentation

Now you just need to run the following command in docs directory:

make html

On windows:

.\make.bat html

Then it should create your documentation in _build\html.

And that’s it, you now have documentation for your code.

Next Steps

After setting up Sphinx, you can use Read the Docs to publish your documentation online. If your project is open-source, you can share your documentation with everyone for free.

Setting up Read the Docs shouldn’t be hard, as you just need to point your GitHub repo — or I think they are okay with a couple of other platforms — and they do the rest.

Reflections

Setting up Sphinx early on gave me more structure and helped me think about how others might use stocksimpy in the future. It’s tempting to skip documentation at the beginning, but tools like Sphinx make it easy and rewarding.

What’s Next?

In the next post, I’ll start building the main file structure as well as some basic indicators like SMA and RSI.

🚀 Follow the Journey

If you’re into Python, finance, open-source, or just love watching a dev project unfold — stick around!

building stocksimpy series

🐈‍⬛ Star this on GitHub
🧠 Follow me on Twitter / X
🔷 I’m now on Bluesky
📰 Or read more of my posts on Medium
💬 Let’s connect on LinkedIn

Thanks for reading — let me know how you would document your code, or would you use sphinx too.

🖼️Blog Cover Generator with Google AI Studio

Suleyman Sade — Fri, 11 Jul 2025 02:36:07 +0000

This post is my submission for DEV Education Track: Build Apps with Google AI Studio.

What I Built

As someone who frequently writes blogs about 🤖 AI and programming. I decided to generate an app that uses Google Imagen to generate cover images for my blog posts.

Here is the full user flow:
✍️ The user inputs blog post content
🧠 Gemini summarizes the theme and proposes a cover image description
🎨 Imagen generates the cover image from Gemini's prompt
🔁 The user gets to download or regenerate

🧪 Here is the prompt that I used:

Create an app that would allow user to input their blog posts/article as a text input, analyze the information with Google Gemini and decide on an appropriate cover image description for the article, and build that cover image using Google Imagen. Give the user the option to download the image or generate a new image.

Demo

🧵 Try It Out

Here’s the full source prompt in Google AI Studio:

🔗 Launch the App in AI Studio

My Experience

The resulting app was exactly what I wanted, but seeing it being coded by AI in just a couple of minutes - well, that was amazing.

Big thanks 🙏 to DEV + Google AI Studio for making it easy (and free) to build cool ideas like this. This was a fast project, but one I’ll actually use regularly.

If you enjoyed reading:

🧠 Follow me on X/Twitter
🔷 Follow me on Bluesky
📰 Check out more of my work on Medium
💬 Let's connect on LinkedIn

I am Building a Python Library from Scratch: Building StockSimPy | Week 0

Suleyman Sade — Thu, 10 Jul 2025 20:55:23 +0000

🛠️ "The best way to learn to code is by building something real."

That's the advice I have seen quite often, and now I am taking it seriously.

I've decided to build StockSimPy, a beginner-friendly Python library for simulating and testing stock trading strategies.

So I am building:

A lightweight, open-source Python library
Focused on readability, simplicity, and education
Designed to help others along the way

Because most of the alternatives I found are generally very hard to use. I just want to create a simpler, educational alternative.

This is not just about building something useful but also about leveling up my skills.

📖 What I hope to learn?

Python object-oriented design
How libraries are structured
Back testing logic
More about Pandas, NumPy and other data related libraries
Building real world projects
And much more…

🔎 How I'm documenting?

I am going to have at least 1 weekly log about my progress on the project, sometimes it might be more depending on my pace.

The code is going to be on GitHub, and it will be updated with each post.

I am going to talk about my mistakes and what I learned along the way.

Here is the GitHub link to the library (still in progress):

🔗 GitHub - SuleymanSade/StockSimPy: A lightweight Python library for back testing stock strategies

🚀 Follow the Journey

If you're into Python, finance, open-source, or just love watching a dev project unfold — stick around!

🧠 Follow me on X/Twitter
🔷 Follow me on Bluesky
📰 Check out more of my work on Medium
💬 Let's connect on LinkedIn

Let’s build something cool together.

More updates coming in Week 1 — stay tuned.

DEV Community: Suleyman Sade

When the Market Takes Weekends Off - Devlog Stocksimpy

Why Add Performance Metrics?

Challenge #1: Counting Days

Challenge #2: AI Boundaries

Challenge #3: Confirming the Accuracy of the Results

Conclusion

Understanding and Coding a Swerve Module in FRC

The Idea Behind Swerve

Defining Constants

Constructing the Swerve Module

Initialization and Setup

Why enableContinuousInput() Matters

Getting the Module’s State

Commanding the Module — setDesiredState()

Preventing Jitter

Optimizing the Wheel Angle

Drive Output Calculation

Turning Output Calculation

Setting Motor Outputs

Putting It All Together

Next Steps:

When a For Loop Powers Your Stock Backtester - Devlog

Yeah, you heard that right.

Strategy

Main Loop

Fixed vs. Dynamic Backtesting

What’s Next

Inside the Portfolio: How Stocksimpy Tracks Trades and Value

From Cash to Stocks: Watch Your Portfolio in Action

Why a Portfolio Class?

Three Core Responsibilities

Storing cash and holdings

Buy and sell operations

Tracking history

Future?

What else?

A change in vision | Building Stocksimpy (Devlog 4)

Imagine being able to test your strategy in less than 10 lines of Python code, rather than spending hours with other libraries. This is what will make Stocksimpy useful.

Creating Stock Data | building stocksimpy 3

Data Validation

Data Import

Data Export

What Losing a Hackathon Taught Me About Code — and Myself

A self-reflection on my past project — DiaGuide — and what I learned about “good code”

Design

Collaboration

What “Good Code” Really Means

🐍 Top Python Libraries to Supercharge Your Productivity

Testing Tools/Libraries

1) Pytest:

Documentation

Sphinx

MKDocs

MKDocs vs. Sphinx: Which Should You Use?

Code Formatting

Black

Ruff

Flake8

Which One Should You Use?

Type Checking

Mypy

Dependency Management

Pipenv

Poetry

Which One Should You Use?

Conclusion: Choose Tools That Scale With You

From SMA to TEMA: Coding Technical Indicators in Python — Building stocksimpy 2

Why Build Indicators From Scratch?

Deep Dive Into Common Indicators

Simple Moving Average (SMA)

Weighted Moving Average (WMA)

Exponential Moving Average (EMA):

Double Exponential Moving Average (DEMA)

Triple Exponential Moving Average (TEMA):

What’s Next?

Setting up proper documentation with Sphinx docs — Building stocksimpy 1

Why Set Up Sphinx Docs Now?

What is Sphinx?

How to Set up Sphinx?

Commanding the Module — `setDesiredState()`

Imagine being able to test your strategy in less than 10 lines of Python code, rather than spending hours with other libraries. This is what will make `Stocksimpy` useful.