{ blog.sunix.org }

Feeling Powerful with Just a Browser: Working Around a Broken Tennis Booking System

Sun, 11 Jan 2026 00:00:00 +0000

I don’t get many chances to play tennis.

Between work, everyday constraints, and lately some pretty uncooperative weather, court time is rare and valuable. So when I finally found a slot that worked — and the booking system refused to give it back — frustration set in fast.

A Slot That Existed… but Didn’t

After canceling a reservation by mistake, I tried to book the same court again.

The global search page clearly showed one available slot for that day.

But when I clicked through to the court page, instead of seeing the list of available time slots and a “Reserve” button, I got this message:

Sorry, there is no court available for the selected date and criteria.

So the platform was telling me two contradictory things:

Search results said the slot existed
The court page claimed there were no slots at all for that day

When you already don’t have much time to play, that kind of bug is incredibly frustrating.

When You Stop Trusting the UI

Refreshing didn’t help. Navigating back and forth didn’t help. The slot stayed visible in search, but the court page refused to display it.

At that point, I stopped trusting the interface.

If the system was able to count the availability, then the data had to exist somewhere — even if the UI failed to render it.

Watching the Site Talk to Itself

I opened Chrome DevTools and switched to the Network tab.

I replayed the booking flow and watched the HTTP requests being made.

One thing stood out:

The same court
At the same time
Worked perfectly on the previous day

Clicking “Reserve” for that earlier date led straight to the reservation confirmation page.

So I captured that request.

Right-click → Copy as fetch → paste into the console.

The Request (Sanitized but Structurally Identical)

Below is the request as captured, with:

A fake domain
A clearly fake anti-bot token
Everything else left untouched to preserve realism

fetch("https://tennisresa.fake/tennis/Portal.jsp?page=reservation&view=reservation_captcha", {
  "headers": {
    "accept": "text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.7",
    "accept-language": "fr-FR,fr;q=0.9,en-US;q=0.8,en;q=0.7",
    "cache-control": "max-age=0",
    "content-type": "application/x-www-form-urlencoded",
    "priority": "u=0, i",
    "sec-ch-ua": "\"Chromium\";v=\"134\", \"Not:A-Brand\";v=\"24\", \"Google Chrome\";v=\"134\"",
    "sec-ch-ua-mobile": "?0",
    "sec-ch-ua-platform": "\"Windows\"",
    "sec-fetch-dest": "document",
    "sec-fetch-mode": "navigate",
    "sec-fetch-site": "same-origin",
    "sec-fetch-user": "?1",
    "upgrade-insecure-requests": "1"
  },
  "referrer": "https://tennisresa.fake/tennis/Portal.jsp?page=recherche&view=rechercher_creneau",
  "referrerPolicy": "strict-origin-when-cross-origin",
  "body": "equipmentId=320&courtId=3012&startDate=2026%2F01%2F14+12%3A00%3A00&endDate=2026%2F01%2F14+13%3A00%3A00&cancelling=false&li-antibot-token=FAKE.JWT.TOKEN_FOR_BLOG_POST_ONLY&li-antibot-token-code=100&captchaRequestId=FAKE-CAPTCHA-ID-123456",
  "method": "POST",
  "mode": "cors",
  "credentials": "include"
});

What I Changed (Almost Nothing)

This is the key point.

I did not attempt to:

Forge a new request
Bypass authentication
Remove the anti-bot mechanism

I deliberately kept the request exactly as generated by the site, because it already contained important context:

Session cookies
Headers
Anti-bot token
Navigation intent

I changed only two parameters:

startDate
endDate

That’s it.

It’s essentially the same as refreshing a POST-based page, but with slightly modified input — like correcting a date in a form the UI refused to let me submit.

The Result

After canceling any pending attempt, I executed the modified request in the console.

I refreshed the page.

And suddenly, I was on the reservation confirmation page — for the exact slot that the UI had claimed didn’t exist.

The backend accepted it.

The booking went through.

That Feeling of Power

I didn’t exploit a vulnerability. I didn’t defeat the anti-bot system. I didn’t “hack” anything in the dramatic sense.

But in that moment, I felt powerful.

With:

A browser
Chrome DevTools
And minimal technical knowledge

…I worked around a system bug that blocked a rare, real-life moment.

What This Really Shows

This wasn’t about hacking.

It was about:

UI and backend desynchronization
Cached or inconsistent availability state
A backend that trusted valid requests more than its own interface

The UI said “no”. The backend said “yes”.

I simply spoke the backend’s language.

Final Thoughts

Websites are just software. Software has bugs. And sometimes, those bugs stand between us and the things we enjoy.

Knowing how to open DevTools doesn’t make you dangerous — it makes you less powerless.

That day, I didn’t just book a tennis court.

I took back control. 🎾

Building a Gift Card Management App with GitHub Copilot: My First Completed Side Project

Fri, 14 Nov 2025 00:00:00 +0000

Like many developers, my life is littered with unfinished side projects. But this time was different. This time, I had GitHub Copilot as my coding companion, and I actually finished. Let me tell you how AI-assisted development helped me build a gift card management application that I actually use every day — and I did it almost entirely without opening an IDE.

The Problem: Managing Gift Cards in the Real World

My wife works at Red Hat, and like many companies, they offer a CSE (Comité Social et Économique) benefit program. One of the perks is getting gift cards with discounts — including a nice 5% discount at a major supermarket chain. Sounds great, right?

Here’s the catch: I was using Google Wallet on my mobile to track these cards, but I could never keep the balance updated. After each shopping trip, I’d forget to update it. Then I’d be at the checkout, unsure if I had enough on the card or not. It was frustrating enough that I decided to build something better — a simple app where I could display the barcode to be scanned at the store and manually update the balance right there.

Another Side Project… Or Is It?

“Alright, here we go again,” I thought. Another side project that I’d start enthusiastically and abandon halfway through. My digital graveyard of unfinished projects was already pretty crowded.

Source: CommitStrip.com - A story we all know too well.

But this time felt different. I had been experimenting with AI tools. I had recently used ChatGPT to build a sample website for a tennis club in just a few days. The speed was incredible. Before starting this gift card app, I even consulted ChatGPT about the technology stack — should I build a PWA (Progressive Web App) or go native with Kotlin? Based on the advice, I decided on a PWA for its cross-platform benefits and easier maintenance.

Still, I was skeptical. Would I actually finish this one?

The Game Changer: Discovering GitHub Copilot Workspace

Then I stumbled upon something that changed everything: the ability to assign entire projects to GitHub Copilot directly in GitHub. Not just code completion or suggestions, but actual project creation and feature development.

I decided to give it a shot. I created an issue with my requirements and assigned it to Copilot. My first prompt was straightforward:

“Create a Progressive Web App for managing gift cards. The app should allow users to:

Store gift card information (name, barcode number)

Generate and display barcodes to be scanned at stores

Track and update card balances

Work offline

Install as a mobile app”

When you assign an issue to Copilot, it immediately creates a “[WIP]” Pull Request and starts working.

And then… I waited. Copilot started working. It created a project structure, set up the PWA infrastructure, implemented the basic features, and even opened a Pull Request. It was like having a junior developer who worked incredibly fast but needed guidance.

The Reality Check: When AI Needs Direction

Of course, it wasn’t perfect. The barcode generation system Copilot created was problematic. Instead of using an existing library, Copilot tried to reimplement Code128 barcode generation from scratch. While the generated barcodes looked right visually, they weren’t compatible with the actual barcode readers at stores. There are nuances to barcode standards — Code128, Code39, EAN-13, and others — each with specific encoding rules that need to be precise down to the pixel.

I created an issue to fix it, but the improvements weren’t quite right either. I got frustrated and did what any developer would do: I asked ChatGPT for help separately, opened up my IDE, started debugging manually. Eventually, I discovered bwip-js, a reliable barcode generation library that handles all the complexity correctly. I manually amended Copilot’s PR to integrate bwip-js, and finally, the barcodes worked perfectly at the store.

Only later did I discover what I should have done from the start: just mention @copilot in the issue comments! When you need Copilot to adjust something, iterate on a feature, or fix a problem, you don’t need to spin up a whole new workflow. Just comment on the issue or PR, mention @copilot, and it will respond and make the necessary changes. This was a game-changer for me.

Finding My Rhythm: The Perfect Workflow

Once I understood how to work with Copilot effectively, I developed a rhythm that actually worked:

Create an issue - Write down what I want in clear, specific terms
Assign it to @copilot - Let it do the heavy lifting
Review the PR - Look at what Copilot created
Provide feedback - Use @copilot mentions in comments for adjustments
Iterate - Repeat steps 3-4 until satisfied
Merge and move on - Deploy and create the next issue

What I loved most was the visibility into Copilot’s “thinking” process. I could see the session logs, watch it reason through problems, and even see screenshots it took when testing with Playwright. It was like pair programming with someone who documents everything they do.

Copilot shows you exactly what steps it’s taking, with checkboxes showing progress. You can see the original prompt and watch it work through each task.

The Pull Request shows all the changes Copilot made, just like any other PR. You can review the diff and request changes.

The workflow became almost meditative. I’d create issues during my coffee break, assign them to Copilot, and come back later to review and comment. No pressure to sit down for a long coding session. No context-switching overhead. Just incremental progress, issue by issue.

The Result: A Finished Project

After several iterations over a few weeks, I had a working app. Not just a proof of concept, but something I actually deployed and use regularly:

📱 Progressive Web App that installs on my phone
📊 Barcode generation using bwip-js that works reliably with store scanners
💰 Balance tracking that I can update on the go
🔒 Offline support so it works everywhere
🎨 Clean UI that’s simple and functional

You can check out the code on GitHub and try the live application yourself.

But here’s what really matters: I finished it. For the first time in years, I completed a side project from start to finish. It’s deployed. It’s in use. It solves my actual problem.

Lessons Learned

Working with GitHub Copilot taught me several things:

AI is a collaborator, not a replacement - You still need to guide, review, and make decisions
Clear communication matters - The better your issue descriptions, the better the results
Iteration is key - Don’t expect perfection on the first try; embrace the feedback loop
Learn the tools - Understanding features like @copilot mentions saves tons of time
Small steps win - Breaking work into issues and letting AI handle them one by one actually works

The Cherry on Top

Want to know something funny? This blog post itself was generated with the help of Copilot. I created an issue asking for a blog post about the experience, provided the structure I wanted (following classical rhetoric: exordium, narration, argumentation, refutation, and peroration), and iterated on the draft with @copilot mentions until it captured my voice and experience.

It’s turtles all the way down.

Final Thoughts

I’m genuinely excited about this new way of building things. GitHub Copilot didn’t just help me finish a project — it changed how I approach side projects entirely. Instead of thinking “I need to set aside a weekend to code this,” I think “I can break this into issues and make progress during coffee breaks.”

The barrier to finishing projects isn’t just time or skill anymore. It’s about having the right collaboration model. For me, that model is now: me plus AI, working asynchronously, iterating on issues, and actually shipping.

If you’ve been putting off that side project, maybe give GitHub Copilot a try. Create an issue. Assign it to @copilot. See what happens. You might just finish something for once.

And when you do, it feels pretty great.

Have you used GitHub Copilot or other AI coding assistants for your projects? What’s your experience been? I’d love to hear about it in the comments below.

Why I Think Git Flow Doesn't Fit Most Projects Anymore

Fri, 07 Nov 2025 00:00:00 +0000

I’ve used Git Flow on quite a few projects over the years — and honestly, I’ve reached a point where I don’t think it’s the right choice for most modern teams anymore.

It’s not that Git Flow was bad. In fact, when Vincent Driessen came up with it back in 2010, it made a lot of sense. We didn’t have solid CI/CD pipelines yet. Releases were manual. Teams were smaller and slower. Having a clean branching model for “features,” “releases,” and “hotfixes” was a huge step forward at the time.

But now? It just feels outdated.

The Problems I Keep Running Into

Every time I see Git Flow used in a modern setup — with automated testing, continuous integration, and frequent releases — it causes more friction than it solves.

Here’s why:

Too much complexity. The number of branches you have to maintain (develop, release, hotfix, etc.) adds unnecessary overhead. Everyone ends up spending time managing branches instead of shipping code.
Messy history. With all the merges going back and forth, the Git history becomes unreadable. You lose the nice, linear flow that helps understand what actually happened.
Outdated assumptions. Git Flow was built for a world of scheduled releases. But with CI/CD, we can deploy anytime — sometimes multiple times a day. The model doesn’t fit that reality.
Long-lived branches and circular merges. These “living” branches constantly merging into each other create confusion and technical debt. It’s too easy to break things accidentally.
Rigid structure. Modern development needs flexibility. You want to be able to test, experiment, and integrate quickly. Git Flow gets in the way of that.

What Works Better for Me

I’ve had much better results using Trunk-Based Development. Everyone works off main (or master), creates short-lived branches, and merges back quickly — ideally after just a day or two. It keeps things simple and stable.

A few key practices that help:

Use git rebase instead of merging in your Pull Requests. It keeps the history linear and easy to read.
Create maintenance branches only when you really need them — for example, to patch already released versions. When that happens, just use git cherry-pick to backport fixes.

This setup keeps your main branch always production-ready, while still letting you move fast.

The “Shift Left” Connection

If your team has already shifted left — meaning you test, review, and automate early in the process — you don’t need extra “safety” branches like develop or release.

CI runs your tests before merging. You can spin up preview environments for every Pull Request. Your main branch stays stable by design.

That’s the world we live in now, and it makes Git Flow’s complexity unnecessary.

So… What Do You Think?

I know this might sound opinionated, and I’m not saying Git Flow should never be used. There are still cases — maybe in projects with slow release cycles or strict approval gates — where it can make sense.

But for most modern teams? I think it’s time to move on.

I’d really like to hear from others:

Are you still using Git Flow?
Have you switched to something simpler like Trunk-Based Development or GitHub Flow?
What’s worked (or failed) for your team?

Let’s talk about it — I’m genuinely curious how others see this shift.

Recovering My Frozen Fedora Laptop

Tue, 31 Dec 2024 00:00:00 +0000

I left Red Hat a few months ago and joined Sciam, but I had to return my corporate laptop. To maintain my workstation setup, I decided to reuse my old Dell XPS and migrate my data from one laptop to another. After installing a fresh Fedora system on the XPS, everything seemed fine initially, but some unexpected issues arose afterward.

The Initial Problem: Intermittent Freezing

After transferring my corporate laptop data to the older machine, I restored my home directory using Deja-Dup. While the backup and restoration process worked smoothly, a significant issue arose: my Fedora system began freezing approximately every 10 seconds for 3 seconds at a time, rendering it almost unusable.

Diagnosing the Issue

I started by isolating the problem to see if it was related to the system itself. Here’s what I did:

✨ Created a New User: I created a new user account on Fedora and tested the system. To my surprise, it worked flawlessly without any freezes.
🔍 Narrowing Down the Cause: This indicated that the issue lay within my home directory. I began moving folders to a backup directory to pinpoint the culprit. When I moved the .config directory and relogged, the freezing stopped. Narrowing it down further, I discovered that the ~/.config/dconf/user file was the source of the problem.

The Solution

To resolve the issue, I moved the problematic dconf file to a backup directory:

mv ~/.config/dconf/user ~/backup/dconf/user

This completely resolved the freezing issue. It appeared that the dconf database had become corrupted or contained conflicting settings. By removing it, the system regenerated a new, clean dconf database.

Lesson Learned: A corrupted dconf database can severely impact performance. Resetting it is an effective troubleshooting step.

Troubleshooting dconf Read/Write Errors

Hoping to retain my configurations, I attempted to back up and restore the dconf database:

💾 Backup:
```
dconf dump / > dconf-backup.txt
```
🔄 Restore:
```
dconf load / < dconf-backup.txt
```

However, when I tried to restore the settings, I encountered the following error:

The operation attempted to modify one or more non-writable keys

To identify the problematic keys, I wrote a script to check the readability of each key in the backup file. Surprisingly, all keys were readable. Despite this, the restoration process failed. Ultimately, I chose to manually rebuild my configuration rather than continuing to debug the permissions issue.

Lesson Learned: When restoring dconf settings proves too difficult, rebuilding configurations manually can be faster and more reliable.

Resetting Deja-Dup Configuration

While investigating the issue, I noticed log entries related to Deja-Dup in journalctl. This raised the possibility that frequent backup operations were causing the freezes. To rule this out, I decided to reset the Deja-Dup configuration.

Using dconf-editor didn’t provide an obvious way to remove or reset Deja-Dup settings. Instead, I took a brute-force approach by deleting the configuration files and reconfiguring the backup settings manually. This resolved any potential conflicts quickly.

Lesson Learned: Sometimes, deleting and starting fresh is the most efficient way to troubleshoot persistent issues.

Adjusting Trackpad Settings

After resetting the dconf database, I noticed changes in my trackpad’s behavior. I had to manually adjust its sensitivity and gestures to restore my preferred setup. While this was straightforward, it served as a reminder of how many small customizations accumulate over time.

Lesson Learned: Keep a record of your preferred configurations to streamline recovery after resets or migrations.

Resolving Guake Shortcut Issues

One of the lingering problems after resetting my settings was with Guake, my dropdown terminal. The shortcut I used to toggle Guake’s visibility (Ctrl+Down) no longer worked. Attempting to rebind it in the Guake Preferences dialog resulted in the following error:

Guake Terminal: A problem happened when binding Control+Down key. Please use Guake Preferences dialog to choose another key.

Ironically, this error occurred while using the Preferences dialog itself! After some trial and error, I stumbled upon a workaround:

💡 In a terminal, I typed guake followed by the Tab key, which revealed a command called guake-toggle.
⚙️ I went to GNOME Settings > Keyboard > Shortcuts and created a custom shortcut.
⌨️ I set the command to guake-toggle and bound it to Ctrl+Down.

This approach worked perfectly, restoring the desired functionality.

Lesson Learned: When standard UI methods fail, alternative commands and workarounds can save the day.

Final Thoughts

Despite the challenges, I am genuinely happy to return to Fedora Linux. Over the past few months, I had been using macOS and Windows, but it’s clear to me that I’m a Linux user at heart. Fedora feels like home—it’s where I’m most comfortable and productive.

Although it wasn’t easy to troubleshoot and resolve these issues, I managed to overcome them and recover an almost perfect clone of my previous laptop settings. This experience reinforced my appreciation for Fedora’s flexibility and the vast potential it offers for customization and experimentation.

Why We Estimate: The True Value of Estimation in Agile Development

Tue, 23 Jul 2024 00:00:00 +0000

Reading the article “4 Fallacious Reasons Why We Estimate”, I felt it missed the most important part of why we estimate. The article seemed to suggest that estimation is only fraught with drawbacks and is ultimately useless. However, from my experience working with various teams at Red Hat, I believe that estimation holds significant value, albeit for reasons that might not be immediately apparent. In this blog post, I will delve into why we estimate, addressing misconceptions and highlighting the true value of this practice.

No Visible Progress, Endless Issues, and Frustration

In one of our sprints, we assigned one task per developer. However, because no one finished their task, we moved all the ‘in progress’ issues to the next sprint. This lack of visible progress can be problematic and frustrating for everyone involved:

Project Manager (PM): The PM is frustrated because they cannot see progress and have no idea if tasks will be delivered in the current sprint, the next one, or even three months down the line.
Team Members: Other team members are frustrated because they want to understand where the team stands in terms of achieving common goals. As a team, everyone wants to reach their objectives together.
Individual Developers: It is frustrating for developers not to be able to finish tasks despite making progress. Marking tasks as done provides a sense of accomplishment, which is crucial for maintaining motivation during the sprint.

Splitting Issues

Let’s consider one of my assigned issues: “Make the factories work with Theia IDE.” One major component was implementing the import of projects defined in the factory definition. This issue could take one or two sprints to complete, but without clear estimation, it was challenging to gauge the time required accurately.

Any task that takes more than a week can be frustrating for the reasons mentioned above. Therefore, my first step was to split the issue into smaller, more manageable tasks that could be “delivered.” Initially, I split the issue into two parts, but I remained open to further splitting if necessary. However, sometimes splitting issues isn’t enough to create clear and concise tasks that can be resolved quickly.

Ending Up with Results

To ensure tasks can be solved within a short period, each task should have a clear definition of done, which could be delivering something, documentation, etc. Here are some examples:

Spike: This could result in more issues or a Proof of Concept (PoC).
Demo Scripts and Acceptance Criteria: These should be defined before estimating issues. Acceptance criteria, following the Given-When-Then pattern, help validate the task’s completion.

For instance, the issue described in GitHub issue #2465 can be easily estimated because the steps to completion are well-defined.

How We Should Estimate

Define the Goal and Clear Definition of Done: Include a demo at the end and/or acceptance criteria.
Maximum 5 Days: If a task is estimated to take longer, it should be split into smaller tasks.
Explain the Time Estimate: Provide implementation details and reasoning.
Use Relative Sizing: In previous teams, we estimated using trivial/small/medium/large to avoid discussing specific timeframes.
Collaborative Estimation: Estimating with team members forces you to think through the implementation. Explaining your estimates can reveal hidden complexities.

Experiments and Spikes

Spike issues involve investigating a technology or figuring out an implementation approach. For example, I spent time figuring out how to implement the import functionality. A spike should result in a PoC or a clear understanding of the task. After a spike, you can create and estimate new tasks more accurately.

Conclusion

While some may view estimation as an exercise in futility, my experience has shown that it provides essential visibility and structure to the development process. Estimations help manage expectations, break down complex tasks, and maintain team morale by showing incremental progress. By understanding and implementing effective estimation practices, we can harness their true value, making our development cycles more predictable and our goals more achievable.

Migrating Gmail from One Account to Another: A Comprehensive Guide

Tue, 09 Jul 2024 00:00:00 +0000

Migrating emails from one Gmail account to another can be a daunting task, especially when you need to ensure that no emails are lost, and all tags (labels) are accurately transferred. This guide will walk you through the process, highlighting the common challenges and the tools you can use to make the migration smoother.

Why Backup Your Gmail?

Imagine you’re leaving your job, and a colleague needs an important email from a customer that you no longer have. Or perhaps you need to consolidate multiple email accounts for better management. Backing up and migrating your emails can prevent data loss and ensure continuity in communication.

Challenges in Migrating Gmail Accounts

When I first attempted to migrate my emails using IMAP with Thunderbird, I encountered several issues:

Inefficiency: The process was slow and could not detect duplicate emails.
Crashes: Thunderbird crashed frequently, and resuming the migration from the last point was not straightforward.
Label Issues: Gmail labels are seen as folders in IMAP, but folders are not labels. If an email had multiple Gmail labels, it appeared as multiple emails in different folders in IMAP.

The Solution: Using mnIMAPSync by Marc Nuri

After struggling with Thunderbird, I turned to a tool developed by my colleague, Marc Nuri: mnIMAPSync. This Java-based IMAP Server syncing tool proved to be much more efficient for the task.

Steps to Migrate Gmail Accounts Using mnIMAPSync

Enable IMAP in Both Accounts:
- In both the source and destination Gmail accounts, go to Settings > See all settings > Forwarding and POP/IMAP and enable IMAP.
Show All Labels in IMAP:
- Ensure that all labels you want to sync are shown in IMAP. In Settings, navigate to the Labels tab and select “Show in IMAP” for each label, except for “All Mail”.
Enable Sign-In with App Passwords:
- Follow Google’s instructions to enable sign-in with app passwords. This is crucial for the tool to authenticate with your Gmail accounts.

Using Docker for mnIMAPSync:

If you don’t have the right version of Java to run the tool, use the provided Docker image. Ensure Docker is installed on your machine.

Run the following Docker command, replacing the placeholder values with your actual account details:

docker run marcnuri/mnimapsync \
  --host1 imap.gmail.com --port1 993 --user1 source-email@gmail.com --password1 apppassword1 --ssl1 \
  --host2 imap.gmail.com --port2 993 --user2 destination-email@gmail.com --password2 apppassword2 --ssl2 \
  --threads 9 --delete

Troubleshooting Common Issues

Labels with Special Characters:
- If labels contain special characters (e.g., /), the tool might crash. Rename these labels without special characters and rerun the sync.
Syncing Large Labels:
- Untick “Show in IMAP” for the “All Mail” label to speed up the process. Alternatively, be patient, as syncing large labels can take time.
Tool Crashes:
- If the tool crashes at any point, simply rerun it. The tool is designed to pick up where it left off.

Conclusion

Migrating emails between Gmail accounts can be a complex task, but using the right tools and following a structured approach can significantly simplify the process. mnIMAPSync by Marc Nuri offers a reliable solution for syncing emails, overcoming many of the limitations faced with other methods.

Remember, this is a task you might need to run periodically, especially if you’re dealing with ongoing email migrations. By following this guide, you can ensure a smooth and efficient transition of your emails from one Gmail account to another.

News from Eclipse Che Google Summer of Code 2016 Projects

Wed, 24 Aug 2016 00:00:00 +0000

Summer is heating up in the Eclipse Che ecosystem. More contributors, including Red Hat and SAP, are joining the Che adventure. Everyone is working hard on Che improvements, such as implementing the Language Server Protocol and multi-container workspaces.

But they are not the only ones working this summer.

Earlier this year, Florent and I submitted a few ideas to the Google Summer of Code (GSoC). The GSoC is a program organized by Google to encourage students to be more involved in open-source projects. Students get a well-paid summer job, and open-source projects gain promising new contributors. As part of the Eclipse Foundation, Eclipse Che is participating in this year’s Google Summer of Code. Codenvy and Serli are also participating as Eclipse Che GSoC project mentors for 2016.

Unit Tests in Che

In Che, Java unit test execution is possible out of the box thanks to Maven. To execute a test class opened in the editor, you can simply create a Maven command in Che:

clean test -Dtest=${current.class.fqn}

You can even connect the debugger to it:

clean test -Dtest=${current.class.fqn} -Dmaven.surefire.debug

However, this is not as good as the unit test UI we have in the classic Eclipse IDE.

As part of the GSoC program, Mirage Abeysekara, a student from Sri Lanka, started implementing a Che extension for unit test execution:

Context menu for running test cases: In the project explorer, right-clicking on a Java test class should show a menu item to run that test class.
Main menu item for running all tests: The main menu bar contains a menu item for running all the test classes in the project.
GUI for showing test runner state: After launching the tests, the test runner window will open and show the current status of the test runner: launching, waiting for results, and finished.
View the details of a failing test: A window will display the failing test cases, including the stack trace and the differences in assertions.
Navigation to the failing class: In the details window, there must be an action to let you jump to the failing test class.
Extendable framework: The test runner plugin must provide an extendable framework for adding new test runner implementations without modifying the REST services and the GUI.

So far, Mirage is in his final steps. You can check out his work at GitHub and view an overview of his online demo on YouTube.

Pair Programming

Separately, Randika Navagamuwa is working on improving an existing prototype for pair programming within Che. This prototype was demoed during the last EclipseCon: InfoQ Presentation.

The prototype shows multiple Che editors connected to the same workspace and modifying the same file. All the editors receive live updates, just like in Google Docs.

Randika is adding new features to the existing prototype and improving the code quality. There’s still a lot to do, but he has already implemented the display of other participants’ cursors. To do this, he had to get involved in two other Eclipse Foundation projects:

Eclipse Orion: Che uses Orion as an embedded editor. Randika made a first demo just with Orion to display additional cursors using annotations.
Eclipse Flux: Used to exchange messages during the pair programming session. Exchanging cursor positions involved registering a new message type in Flux.

Randika is currently refactoring the extension to simplify the implementation of new protocols used for the pair programming session.

A video demo of his work can be found here: YouTube Demo.

For this first GSoC experience, we used Gitter for student/mentor daily communication. Che has also opened a Gitter channel (Eclipse Che Gitter). We preferred this option to IRC, as IRC may be blocked by company firewalls. Generic questions go to the main Che Gitter channel, and specific questions related to the GSoC project go to mentors through direct messages.

We’ve also tried to blog as much as we could about what we were doing during this program.

Randika and I did a lot of instant messaging sessions when things were unclear. We organized video calls when necessary. We even used Che’s pair programming extension for our own pair programming sessions! It works pretty well, even with the Che server running in the US (AWS) and with two clients running in Sri Lanka and France.

I wish all the best to the two students who are very close to their final evaluation! I hope they will continue to contribute to Che even after this GSoC program.

EclipseCon France 2016: Language Server Protocol, Eclipse Che, and Commit Strip

Fri, 24 Jun 2016 00:00:00 +0000

This blog post will soon be available in French on the Serli blog site.

Once again, I spent a fantastic week at EclipseCon France in Toulouse. A huge thank you to the Eclipse Foundation for organizing this amazing event! This year, I learned a lot and had many interesting discussions about Eclipse technologies.

Language Server Protocol

To me, the star of the conference was the Language Server Protocol (LSP), introduced by Microsoft’s TypeScript and its Language Server. It was featured in three presentations:

Language Server Protocol

During the Xtext on Che presentation, Sven described providing Xtext to Eclipse Che. Initially, implementing Xtext for another new editor seemed overwhelming due to the rapid emergence of new editors. Instead, he introduced the TypeScript/VSCode Language Server Protocol, which offers a standardized API reusable by any editor, not just Microsoft’s VSCode.

This approach has two main benefits:

Xtext developers won’t need to create and maintain implementations for each editor.
Eclipse Che will benefit from languages that implement the Language Service SPI.

In his talk, Sven outlined two main initiatives:

Providing an XText implementation of the Language Service SPI
Making Eclipse Che compatible with the Language Server Protocol

During the JSDT talk by Ilya Buziuk and the TypeScript talk by Sebastien Pertus, they highlighted the Eclipse plugin from Angelo Zerr, which uses the Language Server Protocol. This means existing Eclipse JavaScript plugins can be replaced by this new approach.

Eclipse Che

Eclipse Che was another hot topic at the conference, featured in four sessions:

Extending Eclipse Che to Build Custom Cloud IDEs
Code in the Cloud with Eclipse Che and Docker
Xtext’s New Adventures with Che
Lunchtime Demo: Pair Programming in the Cloud with Eclipse Che

In the workshop, attendees learned how to create a custom developer environment for the Go language using Docker and add menu actions in the Cloud IDE.

During the “Introduction to Eclipse Che” talk, Stevan and Florent demonstrated Che Java IDE’s capabilities, from basic code completion to remote debugging. They discussed the concept of universal workspaces and introduced the Github contribution factory link, developed by the Serli team, which enables quick project cloning in a preconfigured Che workspace.

I also did a live demo of my pair programming plugin for Che, showcasing the first step towards a Google Docs-like experience in coding.

CommitStrip

For those who haven’t heard of Commit Strip, check out their comics at Commit Strip. Thomas and Etienne gave a great keynote at EclipseCon France, sharing their experiences as coders through humor and comics in the session Explaining Code to My Mom. My favorite strip is Why Marty and the Doc Might Not Arrive After All.

Other Notable Sessions

Here are some other sessions I attended and enjoyed:

What Every Java Developer Should Know About AngularJS

By Maximilian Koegel and Edgar Mueller [EclipseSource]

This was a comprehensive guide for Java developers wanting to start with JavaScript and AngularJS.

What’s New in Eclipse IDE and the Ecosystem Around It

By Sopot Cela and Mickael Istria [Red Hat]

This talk covered upcoming features in the Neon release, including theme enhancements, text editor zoom, substring completion in JDT, smart project import, auto-save, and auto-suggest editors in the marketplace.

The State of Docker and Vagrant Tooling in Eclipse

By Roland Grunberg [Red Hat]

Roland presented the current status and future plans for Docker and Vagrant tools in Eclipse.

Java 9 Support in Eclipse

By Sasikanth Bharadwaj [IBM]

This session provided an overview of Jigsaw support in Eclipse and how to create and configure Jigsaw modules.

JSDT 2.0

By Ilya Buziuk [Red Hat]

JSDT is being renewed with features like running/debugging Node.js code, a JSON editor, and Grunt/Gulp support.

TypeScript: Feedback from a Real-Life Project within TypeScript and the Future of JavaScript

By Sebastien Pertus [Microsoft]

This talk included live demos of various TypeScript features using Eclipse tools.

Fast Unit Tests for Eclipse Plugins - Possible Architectures and Available Tooling

By Aurelien Pupier [Red Hat]

Aurelien shared his experience with unit testing in Eclipse plugin development, discussing different setup options and productivity tools.

A Generic REST API on Top of Eclipse CDO for Web-Based Modelling

By Christophe Ponsard

This session demonstrated a modeling application running EMF behind the scenes with a web UI.

Conclusion

That’s all for now! Apologies for not covering other topics like IoT, Science, and Modeling. I will update this blog with links to recorded talks as they become available.

Thank you to the EclipseCon organizers for a great event!

PS: Special thanks to David Gosling, Stevan Le Meur, Florent Benoît, and Aurélien Pupier for the review.

A Universal Eclipse IDE

Mon, 16 May 2016 00:00:00 +0000

This year, I am participating in Google Summer of Code as a mentor for the Eclipse umbrella organization. I’ve submitted a few ideas about Eclipse Che and Eclipse Flux, and some of them have been selected. I am mentoring the project “Pair Programming with Eclipse Che,” which involves improving an existing prototype I demonstrated at various developer conferences. You can check out the GitHub pair programming Che extension.

A few days ago, my padawan Randika encountered issues setting up his Eclipse IDE on the latest Ubuntu. He faced problems with GTK3 and experienced strange performance issues. I suggested he run the Eclipse IDE inside a Docker container, which worked fine. However, since we are not in the same location, it was difficult to assist him with advanced IDE configurations like GWT super dev mode.

I posted in our Gitter chat room, “Let’s try something fun,” and we decided to launch Eclipse IDE inside an Eclipse Che Docker workspace hosted by Codenvy beta. When I posted a screenshot of this a few hours later, I received a lot of interactions on Twitter from the community: “Say whaaat?”, “WTF? :)”, “Got some more info? :)“, and “Worth writing a blog post on how to set this up?”

Eclipse Mars Running Inside Eclipse Che

Randika ended up writing a blog post explaining how we did this: Run Eclipse Mars IDE inside Che. This trick helped me assist Randika in setting up his GWT super dev mode in Eclipse Mars, though it wasn’t anything revolutionary like Che.

Universal Eclipse IDE

So, what’s next? You might have seen Tyler’s keynote at EclipseCon 2016 about “Universal Workspaces” EclipseCon keynote. Here are my thoughts on building a Universal Eclipse IDE.

In Randika’s demo, although “ssh -X” worked fine on our local computer, I experienced some latency when it ran in the Cloud. On the other hand, Che lacks many features and can’t yet fill the gap compared to the classic Eclipse Desktop IDE. Additionally, when you install an Eclipse IDE plugin, it prompts you to restart. But why? Isn’t it running on OSGi, one of its key features? I’ve heard someone say the problem lies with SWT and that it should be replaced with JavaFX. I believe we should use web technologies because they are the present and the future.

So, I have a dream: that one day, every single Eclipse plugin will have its services exposed in REST and/or WebSocket.

I have a dream that Eclipse developers can write plugins that work for both Che and the classic Eclipse IDE.

I have a dream that Che developers won’t reinvent the wheel but will reuse Eclipse IDE core OSGi bundles.

I have a dream that we won’t have to restart our IDE after installing a plugin.

I have a dream that one day we will all use a Universal Eclipse IDE.

Yes, We Can!

In my opinion, this isn’t that hard to achieve:

The Eclipse core bundle could expose a REST API or WebSocket. We would need an additional “org.eclipse.bundle.web” alongside the “org.eclipse.bundle.ui,” both using the “org.eclipse.bundle.core” bundle. Eclipse would run with a Jetty HTTP server bundle.
We would run a headless Eclipse IDE inside a Che Docker-based workspace with X forwarding.
Eclipse Che cloud IDE client extension and Orion could connect to these Eclipse web services.
Alternatively, we could improve Eclipse Flux, which started something similar.

Everyone would benefit from this:

Che could reuse existing bundles of the Eclipse IDE.
Che could access plugins from the existing Eclipse Marketplace.
For the Eclipse Desktop IDE, it would be time to rethink the design and decouple the UI from core services.
JavaScript works everywhere, eliminating the need to maintain SWT graphical libraries for each target architecture.
We could use any UI library and even mix them: SWT for navigation, GWT for view content, pure Orion JavaScript for the editor, and AngularJS for the marketplace.

Recap

To me, the Eclipse Universal IDE would be:

Eclipse Che with a Docker-based workspace
Eclipse IDE running in the container
Eclipse IDE exposing web services
Eclipse Che Cloud IDE (the client side running in the browser) consuming services exposed by the Eclipse IDE and core services exposed by the Che server

Eclipse Flux could be an option for the communication layer.

VGA External Projector Not Detected with Ubuntu on Dell XPS 13

Sun, 20 Sep 2015 00:00:00 +0000

Just got back from an amazing Jug Summercamp at La Rochelle. I was ready for the presentation of the Live Pair Programming with Eclipse Cloud Development and … AGAIN! I faced display issues with the external VGA projector not being detected on my computer, the same issue I encountered a few months ago at Eclipse Con France. Here’s how I managed to resolve it.

Problem Description

When I plugged the VGA cable into my display port, the projector displayed “SEARCHING …”. No screen was detected on my laptop’s configuration screen. Interestingly, the setup worked fine in another room, which made me suspect an issue with the extension of the VGA cable.

Laptop Specifications

Operating System:

Linux Ubuntu Trusty

Laptop:

Dell System XPS L322X

Display Device:

00:02.0 VGA compatible controller: Intel Corporation 3rd Gen Core processor Graphics Controller (rev 09)

The laptop is connected to the external screen projector using a VGA cable and a mini-display-port to VGA adaptor.

Fix

The following steps outline the fix. Note that eDP1 refers to the main laptop screen and DP1 refers to the external screen. Use the xrandr command to get the status of your display:

Screen 0: minimum 320 x 200, current 1920 x 1080, maximum 32767 x 32767
eDP1 connected primary 1920x1080+0+0 (normal left inverted right x axis y axis) 294mm x 165mm
   1920x1080      60.0*+   59.9     40.0  
   1680x1050      60.0     59.9  
   1600x1024      60.2  
   1400x1050      60.0  
   1280x1024      60.0  
   1440x900       59.9  
   1280x960       60.0  
   1360x768       59.8     60.0  
   1152x864       60.0  
   1024x768       60.0  
   800x600        60.3     56.2  
   640x480        59.9  
VGA1 disconnected (normal left inverted right x axis y axis)
HDMI1 disconnected (normal left inverted right x axis y axis)
DP1 disconnected (normal left inverted right x axis y axis)
VIRTUAL1 disconnected (normal left inverted right x axis y axis)

Choose a resolution that works with the external monitor and ensure your VGA cable is plugged in before running these commands:

# Set the main display to the desired resolution
xrandr --output eDP1 --mode 1280x1024

# Add the mode resolution to the external projector
xrandr --addmode DP1 1280x1024

# Activate the output for the external projector using a clone of the main display
xrandr --output DP1 --mode 1280x1024 --same-as eDP1

Wait for 5 seconds and it should work!

Using Arandr

(Edit 21/01/2015)

You can also use the GUI tool Arandr to generate xrandr commands.

It generates scripts like this:

$ cat ~/.screenlayout/clone.sh 
#!/bin/sh
xrandr --output HDMI1 --off --output VIRTUAL1 --off --output DP1 --mode 1920x1080 --pos 0x0 --rotate normal --output eDP1 --mode 1920x1080 --pos 0x0 --rotate normal --output VGA1 --off

So, each time I need to clone my screen, I can just execute the script … et voilà!