MoreRSS

site iconThe Practical DeveloperModify

A constructive and inclusive social network for software developers.
Please copy the RSS to your reader, or quickly subscribe to:

Inoreader Feedly Follow Feedbin Local Reader

Rss preview of Blog of The Practical Developer

🔐 Cryptol — The Language Designed Specifically for Cryptography and Security Proofs

2025-11-29 19:00:42

What is Cryptol?

Cryptol is a domain-specific programming language created for designing, testing, and verifying cryptographic algorithms. Instead of writing encryption logic manually in C, Rust, or assembly, Cryptol allows developers to express cryptographic operations mathematically — then automatically generate fast and verified implementations.

It’s used by government agencies, security researchers, and formal verification teams to ensure algorithms behave exactly as intended.

Specs

Language Type: Cryptography-focused DSL

Created By: Galois, Inc.

First Release: ~2008

Execution Model: Interpreter + formal verification backends

Paradigm: Functional, bit-vector and stream-oriented

Typing: Strong static typing with fixed-width integers

Example Code (Simple XOR Cipher)

cipher : [32] -> [32] -> [32]
cipher key block = key ^ block

cipher 0xABCD1234 0x01020304

A toy block cipher round:

round key state = (rotateLeft state 3) ^ key

Cryptol treats binary values and fixed-width sequences as first-class citizens.

How It Works

Cryptol focuses on cryptographic correctness and formal reasoning. Every value has a bit width by design:

  • Bit → single binary bit
  • [n] → n-bit vector
  • Sequences → streams or blocks

The language includes:

Feature Use
Bit manipulations XOR, shifts, rotations
Pattern matching Protocol/state transitions
Type inference Ensures correct encryption block sizes
SMT solver integration Automated proof checking
Test generation Automatic random testing

Cryptol models algorithms like AES, DES, SHA-256, ChaCha20, and more.

Strengths

  • Built specifically for cryptographic correctness
  • Predictable bit-level behavior
  • Integrates with proof and verification tools
  • Can generate test benches and formal models automatically
  • Used in military, aerospace, and high-assurance security systems

Weaknesses

  • Not a general-purpose language
  • Small developer ecosystem
  • Requires understanding of cryptographic math
  • Debugging can become abstract and formal

Where to Run

Cryptol runs via:

  • Official Cryptol toolchain and REPL
  • VS Code extension support
  • SMT proof engines (Z3, Boolector, etc.)
  • Hardware integration (CoreIR, SAW verification framework)
  • Limited online sandboxes and TIO.run (restricted)

Should You Learn It?

  • For cybersecurity, cryptographic engineering, or protocol verification: Yes
  • For normal application programming: No
  • For formal verification hobby projects: Interesting
  • For esolang/fun experimentation: Unusual but cool

Summary

Cryptol isn’t just another programming language — it’s a tool for expressing and guaranteeing the correctness of cryptographic systems. While niche, it represents one of the most rigorous approaches to designing secure algorithms, making it valuable for developers working at the intersection of math, software, and security.

FOSS4G Auckland 2025

2025-11-29 18:53:36

Kia ora! Last week, we were in Auckland, New Zealand, for FOSS4G 2025. We had a great time and gave four talks about various topics from GTFS to GeoArrow. Thanks so much to the organizers for putting on such a fantastic conference, and to everyone who came to our presentations!

For those who missed the talks, no worries——we share the slides in this post below. You can click the image to jump to the slides.

Yutani is talking about GeoArrow

As you know, the next global FOSS4G conference, FOSS4G 2026, will be held in Hiroshima, Japan (30 Aug - 5 Sep, 2026). We are looking forward to welcoming you, as part of the broader Japanese geospatial community!

Sheeps

Make It Easier to View GTFS : Building a GTFS Timetable Viewer with SvelteKit (by Xinmiao Qu)

slides

Implementing Longest Path Analysis in QGIS with NetworkX and Python (by Xinmiao Qu)

slides

Interactive Simulation for Visualizing Bus Locations Using GTFS Data (by Kei Yamazaki)

slides

GeoArrow on Web; Can We Live Without GeoJSON? (by Hiroaki Yutani)

slides

Terraform Project Structure Best Practices

2025-11-29 18:50:21

Hello People, In this blog we will deep dive into the Terraform Project Structure Best practices.

Have you wondered that while we are running commands like terraform plan or apply we are not giving any parameters additional to that terraform commands, how does terraform know which file it should execute.
The answer is simple, whenever you run terraform commands like plan or apply, terraform executes that on all the files having .tf extensions. It doesn't matter to terraform if you have a single file with 1000 lines or 100 .tf files with 10 lines. Terraform is that smart. But we humans are not that smart just joking, we are smart too but in use cases like debugging or modifying any specific resource, do u think it is feasible to go through a file of some thousands of lines.

So For this purpose, we will be using project structure in terraform where we will divide the code into multiple .tf files based on their usecases or creation.

Terraform File Loading

Terraform loads all .tf files in the current directory
Files are loaded in lexicographical order (alphabetical)
File names don't affect functionality, only organization
All .tf files are merged into a single configuration

Recommended File Structure:

project-root/
├── backend.tf           # Backend configuration
├── provider.tf          # Provider configurations
├── variables.tf         # Input variable definitions
├── locals.tf           # Local value definitions
├── main.tf             # Main resource definitions
├── vpc.tf              # VPC-related resources
├── security.tf         # Security groups, NACLs
├── compute.tf          # EC2, Auto Scaling, etc.
├── storage.tf          # S3, EBS, EFS resources
├── database.tf         # RDS, DynamoDB resources
├── outputs.tf          # Output definitions
├── terraform.tfvars   # Variable values
└── README.md           # Documentation

File Organization Principles

Separation of Concerns: Group related resources together
Logical Grouping: Organize by service or function
Consistent Naming: Use clear, descriptive file names
Modular Approach: Keep files focused on specific areas
Documentation: Include README and comments

In the above image you can see how we have defined the project structure in Terraform, where we have divided our terraform configuration into multiple files with their usecases.

  • main.tf which contains all the resource definitions. This can be further divided on the basis of resources like ec2.tf, s3.tf, vpc.tf, iam.tf, role.tf.... and so on.
  • Variables.tf: It will contain all the input variables, so if anyone want to see what all the variables we are passing to this terraform code, he can have a look at this and can have a clear info.
  • output.tf: Defines what information to display after running terraform apply or if u want to pass any resource information or data to another resource while creating.
  • versions.tf: Locks terraform and pproviders versions for consistency.
  • providers.tf: Configure cloud provider settings.
  • backend.tf: Configure where Terraform stores statefile.
  • terraform.tfvars: Defines the actual varibale values passed for your environment. You cannot push it to GitHub as it may contain sensitive information.
  • terraform.tfvars.example: It is like a template showing what variables need values, It can be pushed to Github as it more of a template
  • .gitignore: It is a file where you will keep all the files which you do not want to be pushed into the GitHub like the statefile, varibles file. Some of the examples include: .terraform*, *.tfstate, .terraform.lock.hcl, *.tfstate.backup...

Advanced File Organization Patterns

Environment-Specific Structure: We can use separate folders for separate environments like below not including all the files in a single page.

environments/
├── dev/
│   ├── backend.tf
│   ├── terraform.tfvars
│   └── main.tf
├── staging/
│   ├── backend.tf
│   ├── terraform.tfvars
│   └── main.tf
└── production/
    ├── backend.tf
    ├── terraform.tfvars
    └── main.tf

Best Practices

Consistent Naming:

  • Use clear, descriptive file names.
  • Follow team conventions
  • Use lowercase with hyphens or underscores

Logical Grouping

  • Group related resources together
  • Separate by AWS service or function
  • Consider dependencies when organizing

Size Management

  • Keep files manageable (< 200 lines)
  • Split large files by functionality
  • Use modules for reusable components

Dependencies

  • Place provider and backend configs first
  • Define variables before using them
  • Output values at the end

Documentation

  • Include README.md
  • Comment complex configurations
  • Document variable purposes

Commands for Testing:

terraform validate - To Validate the reorganized structure

terraform fmt -recursive - To format all files consistently across folders

terraform plan - Plan to ensure no changes

terraform apply - Apply if everything looks good

Conclusion:

Terraform's Project Structure is a important thing which many will ignore at first includes all the code in a single file and then later struggle while debugging. So It is better to organize our code separately using file structure which will be helpful for us when we got struck with any errors or dealing with microservices and also easy for anyone to have a quick look and understand what is happening under the hood. See you in the next blog.

Below is the Youtube Video for reference: Tech Tutorials with Piyush — “AWS Terraform Project Structure Best Practices”

Beas Kund Trek: A Stunning Adventure Through Kullu-Manali Valley

2025-11-29 18:46:21

The Beas Kund trek is where the wild heart of Manali opens into sweeping meadows, icy streams, and peaks that cut through the sky like ancient guardians.
Every step feels like walking deeper into a postcard carved from the Himalayas. The trail winds through lush valleys and alpine landscapes, leading to the sacred glacial lake believed to be the source of the Beas River, quiet, pristine, and unreal in its beauty.
If you crave a Himalayan journey that blends serenity with thrill, Beas Kund is the trek that stays with you long after your boots return home.

Where the Valley Turns to Magic — Beas Kund Trek

Standing before towering peaks and icy streams, Beas Manali becomes more than a destination; it’s the doorway to one of Himachal’s most loved treks. This package is designed for those who want the raw beauty of the Himalayas without complications, offering a crisp and scenic journey into glacial landscapes and alpine silence.
Package Details

Trekking from Manali

2 Nights and 3 Days

₹ 5,000 per person

Inclusions

  • 1. - Certified Leader
  • 2. - High Quality Safety Equipment
  • 3. - Trek at an Altitude of 12,772 Feet
  • 4. - Accommodation: Alpine or Dome Tents with Quality Sleeping Bags
  • 5. - Meals: Breakfast, Lunch, Snacks & Dinner (All Veg Meals)
  • 6. - Permissions: All Necessary Permits and Entry Charges
  • 7. - Transport from Manali to Dhundi and Return
  • 8. - Campfire Sessions
  • 9. - Trekking Gears if Needed (Microspikes & Gaiters) Every trail, every step, and every sunrise builds up to that final moment where the mountains meet crystal meltwater, the Beas River ending point that makes the trek unforgettable.

Why Go for the Beas Kund Trek — What Makes It Worth It

Choosing the Beas Kund Trek best time to visit means witnessing nature at its most alive. During favourable months, the trail opens into sprawling meadows, ice-fed streams, and crisp mountain air that makes every step feel deeply refreshing.
The route begins with a scenic drive from Manali to Solang Valley, followed by a trek through lush green landscapes that lead you closer to one of the region’s most breathtaking high-altitude lakes.
The journey takes you through open grasslands, glacier basins, and towering peaks that reflect beautifully in the emerald waters of the lake. The mythological roots and the serene ambience surrounding Rishi Vyas’ sacred bathing site add a layer of reverence to the experience.
Here, the birthplace of the Himachal Pradesh Beas River becomes more than a viewpoint; it becomes a memory etched in tranquillity and awe.
Day 1 introduces you to BakarThach with vibrant alpine meadows and a glacier backdrop, making it an ideal place for your first camp.
Day 2 takes you into the heart of the trek, to Beas Kund itself, where snow-draped peaks mirror into the still waters.
Day 3 winds you back to Dhundi and onward to Manali, wrapping the adventure with peaceful satisfaction and a backpack full of moments.
From the valley views to the myth, landscape, and the thrill of standing before Beas Kund, this trek promises beauty, peace, and a powerful sense of arrival.

Conclusion

The Beas Kund Trek leaves you with more than just photographs; it gifts you silence, sky-high horizons, and memories shaped by ice, wind, and wild alpine meadows.
Walking through Kullu-Manali’s raw beauty is an experience that stays long after the trail ends, and the high-altitude lake shimmering beneath towering peaks only deepens the connection.
If you’re seeking a trek that balances serenity, challenge, and legendary landscapes, Beas Kund stands unmatched, an adventure worth every step.

Explore My GitHub Projects — Building, Learning &amp; Shipping

2025-11-29 18:45:29

Hey Dev Community! 👋

I’ve been actively building and sharing projects on GitHub, and I wanted to highlight my work for anyone interested in exploring, collaborating, or giving feedback.

🔗 GitHub Profile:
👉 https://github.com/Huzaifa-io/

💡 What You’ll Find There

Here’s a quick snapshot of what I’ve been working on:

🧩 Open-source projects

From automation tools to small utilities, I'm constantly experimenting and building solutions that solve real problems.

📚 Learning-focused repos

I document my learning journey through structured notes, code experiments, and mini-projects that help me deepen my skills.

⚙️ Clean, documented code

I try to keep my repositories beginner-friendly, readable, and well-organized—perfect for people who want to learn or contribute.

🤝 Open to Collaboration

If you want to contribute, open an issue, start a discussion, or drop a PR—I'd love to connect and build something together!

⭐ If you like my work…

Feel free to star, fork, or follow my GitHub to stay updated.
Your support helps me create even more projects for the community. 🙌

Thanks for reading! Let me know what you think—or share your GitHub link below so I can check out your work too!

Ladybird Browser in an Embedded Web Runtime

2025-11-29 18:44:57

Originally posted on Medium

In my previous blog post, I showed how to build and create an experimental web runtime using Isar, Debian Bookworm, and WPEWebKit. In that post, I also mentioned that I had a Ladybird version incubating. Now it’s time to reveal it.

Ladybird is a completely new browser, built from scratch instead of relying on any existing browser codebases. It has its roots in SerenityOS, but has since diverged into its own project. The project is still in its early phases, so I didn’t expect much to work. To my surprise, it’s already rendering pages quite well. Even WebGL works!

Integrating Ladybird

Ladybird depends on components that aren’t available in Debian Bookworm, such as the Skia and ANGLE graphics libraries. For those, I created dedicated recipes.

It also requires newer versions of some Debian libraries that aren’t in Bookworm or its backports repository (e.g. libpng with APNG support). For those, I ended up creating a backports repository of my own.

Custom Debian Backports

I created a new GitHub repository, debian-backports, which includes a GitHub Actions workflow that downloads package source tarballs from upstream repositories and overlays Debian build rules.

The workflow uses QEMU to build both amd64 and arm64 versions of the Debian packages. Finally, it publishes the APT repository (created with reprepro) to GitHub Pages.

The repository is available at: kodegood.github.io/debian-backports

Isar/BitBake Recipes

As mentioned, I wrote new recipes for some dependencies like Skia and ANGLE, and then for Ladybird itself.

I also applied a couple of patches on top of Ladybird. The main one strips out the browser chrome from Ladybird’s UI, since that’s not needed in a web runtime.

Ladybird uses Qt as its UI library on Linux and Windows. For now, I simply commented out parts of the code, but since Ladybird has a web content view API, a better long-term approach would be to implement a separate lightweight Qt content view.

Isar image flow

Demo

The demo setup is similar to what I had with the WPE version

  • Debian Bookworm as the base platform
  • A slightly customized Weston IVI-shell
  • Ladybird browser, built from source
  • Hardware: Raspberry Pi 5

Known issues:

  • IME integration is not working, meaning no virtual keyboard
  • YouTube is not working. For now, Big Buck Bunny plays via a local page and local file using the video tag

Results

From the build configuration menu you can select Ladybird to be built.

KAS build menu

Finally, after flashing the image to the Raspberry Pi 5:

Note: This is just a tech demo, not a full production web runtime

If you’d like to try it, the project’s README has setup instructions.

The project is available on GitHub as webruntime-debian.