Tag: open source

EmpGrid Post-Mortem (and Resurrection!?)

Jeroen

This post is about my pet project EmpGrid. But first a short story about how I work.

About Promises

I try to be extremely precise with promises. In fact, you could say my Promises work very much like the native JavaScript promises. Let’s look at some code:

We can note some things about that code:

  • The promiseSome(thing) bit should always complete successfully, and always return a real, concrete promise;
  • After that, the then(...) bit will be executed nearly always, i.e. typically a promise resolves successfully;
  • Only in exceptional cases, with a typically well-defined error, will the catch(...) occur.

And that is exactly how real-life promises work for me too. I want people, most notably me, to be able to count on a promise being fulfilled (given normal circumstances).

So, why is this relevant to EmpGrid? Well, I promised myself this for 2018, Q3:

Finalize EmpGrid: finish it XOR do a postmortem

So, this post is that finalization. Because I promised!

EmpGrid Post-Mortem

Since I have not fully finished EmpGrid, the only option I have to fulfill my promise is to write a post-mortem about it.

The idea behind the project remains the same since its inception. It should be a self-contained web application that shows for a group of employees (colleagues) where you can find them online. Typically, you’d be interested in all their “Presences”, ranging from social media (Twitter, LinkedIn) to version control sites (GitHub, GitLab, etc.).

The intended side-effects of the project also remained the same. The repository should be slightly over-engineered, since it should serve as a playground to test technologies useful in larger applications. At least for the server-side bits; client-side a first version could do with a very simple monolithic single page application.

If you clone the repository today, you get a mostly functional thing. You should be able to run it out of the box (given you have a modern .NET Core development setup), and do some CRUD stuff. However, it is not at all “finished”. So, I’m declaring the project dead today, Saturday, September 22nd, 2018.

Here’s what’s still sorely missing:

  • Some kind of user management. Currently, you can only use the built-in seeded admin user with default password. You should at least be able to change the admin’s password. But really you should also be able to create logins linked to Emps, so that people could edit their own details.
  • Persistence. I really wanted to step outside the default EF Core solution that .NET Core pushes you towards. Instead, I would like to see some kind of open source document database integrated. Just haven’t gotten around to it.
  • Cloud-deploy-friendliness. It should be a breeze to deploy the app as a single unit, while still giving a clone-and-run developer experience. Possibly Docker would come in to play.

In addition, there’s a bunch of smaller to do items in the readme left. But the bottom line is: it’s not finished yet.

And that’s okay! Because I learned a lot while building it. Also, the truth is that I spent my time elsewhere past months. And that was a conscious (and wise) choice.

Still, I’m a little sad to declare EmpGrid dead before it got up and running somewhere…

Resurrection?!

So perhaps I should resurrect the project?

Well, not immediately. Or, more specifically, I will not promise that it’ll be resurrected. For one, I’m due for a long, relaxing vacation to Sri Lanka. And second, I see several other cool ventures coming up (hello Advent of Code!!). So perhaps EmpGrid will stay dead.

Or maybe I need a partner in crime?

Time will tell. For now: good bye, EmpGrid. Hibernation mode: on.

What have you done for me lately? (Sep 2018)

Jeroen

In December 2017 I wrote a similar post. Over the past few months I’ve been busy with other projects (writing and non-writing), and I’d love to aggregate them all here in a single post.

So, here’s some stuff from the recent past:

Some things that are in progress:

  • 2018-09-xx: Part 2 of the “Auth0 and Angular 6” blog series is forthcoming on infi.nl
  • 2018-09-xx: A status report on my EmpGrid project is in progress

Finally, some stuff I hope to be writing about in the near future:

Stay tuned!

Extracting and Publishing closed bits as Open Source

Jeroen

There’s a project at work that’s got all the traits to serve as a great vehicle for dabbling some more with open source:

  • Small-but-not-too-small;
  • Self-contained;
  • Not too specific (e.g. to our domain);
  • Keeping the IP safe isn’t a concern since it’s just a small tool unrelated to the core business (i.e. we’ve got “the okay” to make it open source);
  • It might be of some use to someone else, and failing that it’s still fun to open source it;

While trying to start with the process of extraction and open sourcing, there seem to come up a million things to think about when going through this process. I want to gather my thoughts (by writing this post) and untangle that mental mess, so that I can get to a clear plan of attack. Perhaps this post will even be of use to someone else, somewhere.

Context

Currently, the bits I want to make open source are only slightly coupled to the bits I want to keep closed. That is: currently everything is in one solution, but the split in projects already clearly demarcates what would be open and what would remain closed. To put this in a tabular overview (where “Foo” is the closed bit, and “Bar” is the open bit):

Current Situation

Closed Source

/Foo.App
/Foo.App.Tests
/Foo.Core
/Foo.Core.Tests
/Foo.MyInstances
/Foo.ConsoleWrapper
/Foo.ServiceWrapper

 Target Situation

Open Source

/src/Bar.App ???
/src/Bar.App.Tests ???
/src/Bar.Core
/src/Bar.Core.Tests
/src/Bar.ConsoleWrapper
/src/Bar.ServiceWrapper

Closed Source

/packages/Bar ???
/Foo.MyInstances
/Foo.WindowsService ???
/Foo.Console

There are some question marks in that overview. Elaborating on them a bit:

  • I’m not sure if the distinction between “Core” and “App” should remain a dll/project splitup as opposed to possibly a namespace split.
  • I’m not sure how the Open Source solution will be included in the closed source app (via NuGet, or as external source or binaries, or…?).
  • I’m not sure if I can easily distribute a generic windows service wrapper, or if I need to create it in the closed source solution after all.

In addition to these source-related questions, there are other things to think about as well. So next up:

What things to think about beforehand?

Let’s summarize all the things I can currently come up with that might be important in this process, in no particular order, merely numbered to be able to reference them easily:

  1. Project, Namespace, and DLL structure: what’s wise, what’s neat, what’s useful?
  2. Folder structure: how will the repository be structured? What’s future proof here?
  3. Initializing git: currently, the project history is in our corporate TFS. So not even sure if/how to keep the history intact, or if that’s even feasible.
  4. License: okay, that’s not too difficult, but have to choose one nonetheless.
  5. GitHub setup. What’s a good setup? Should I make the organization main owner of the repo, with a personal fork from which I do pull requests?
  6. NuGet packaging: how does this even work? As an application developer I had never had the need to learn how any of this works.
  7. Re-including the open sourced bits in my closed source solution: via NuGet, as external source, or as external binaries?
  8. Choosing a name. One which is not already in use for some software, where a domain with “normal” extension is still avaible, where the name is not taken on GitHub yet, etc.
  9. .NET Core. From my rss feeds I gather that it can be a quite fuss to make open source projects .NET Core “proof”, but it would be yet another thing to tackle while starting this whole thing off. Perhaps something for later? Or is that a grave mistake?
  10. What am I forgetting? I’ve been looking at some of the “top” C# GitHub projects (Restsharp, NodaTime, dapper-dot-net, AutoMapper) and their git history to see how they have evolved, to find out if I’m forgetting anything.
  11. Decent starting point, code-wise: I might be setting unreasonably (and unnecessarily) high standards for the initial commit, but still something to consider. What is the minimum quality I’m requiring before opening the source?
  12. Early feedback: it might be useful to get friends and colleagues to review the setup and get the first version(s) of the repository just right.
  13. Logo: yeah, this project needs the best. logo. ever!

In addition, there’s a practical point: once I split off bits to an open source project, I’ll effectively have two (source-control-wise unrelated) forks of the same code-base, until I’m ready to make my closed source solution depend on the open source bits again.

In Conclusion

After writing the above: wew! No wonder I was not getting anywhere: my mind was just wandering in circles through all of the above points. And I guess “Perfect is the enemy of Good”, or some such. Time to tick off some of the above items.

Google Code Hg Hosting

Jeroen

A few months back I wrote a short comparison of Hg Hosting Providers, followed by a post about CodePlex Hg Hosting. In the mean time I’ve also tested creating a Bitbucket project, but I’ve neglected writing a post about the experience. I may get back on that some time, but first I would like to share my more recent experience with Google Code.

Note that I’m not ready (read: “proud enough”) to share the actual project I’m hosting, as it’s still in (and may never leave) prototype status. Once it’s worth viewing, I’ll probably be doing a short blog post about the project itself.

Without further ado, let’s jump in!

Sign Up and Project Creation

In this case I’m not writing much about sign up. You need a Google account, which most folks will probably already have. If, like me, you are already signed in to your account, nothing more is needed here.

On to project creation, which was surprisingly simple. The process is one step total:

Creating a Google Code Project
Creating a Google Code Project

Very similar to the CodePlex project creation. To note the differences:

  • It’s not entirely clear in Google Code how the project name would become part of the project URL.
  • Source control at Google Code (understandably) excludes TFS.
  • Google Code asks you to label (tag?) your project at creation time.
  • Most importantly: Google Code requires you to pick a license at project creation time.

That last one is really the only difference from CodePlex, but a big one at that! With CodePlex you get a one-month “Setup Mode“, which means your project is private and you can still work out the details (including picking an appropriate license). This is a big plus for CodePlex, especially if (like me at the time) you’re creating your first open source project.

Importing the Existing Repository

Where I had some cautionary steps importing my existing repository the previous time around, this time I had only one, making a total of four steps to get my existing repo pushed to Google Code:

  1. Create a temporary “copy-paste-backup” of my (existing) repo folder.
  2. Clone the Google Code (empty) repo locally.
  3. Copy the existing repo into the empty repo.
  4. Push the repo.

Step one turned out to be superfluous. So, this is in fact easy as pie.

Google Code Features Overview

Here’s my first impression of the various features of a Google Code project:

  • Project home is what you see when you land on the URL of your project (which is in the format: http://code.google.com/p/project-name)
  • Downloads is where you can host releases you’ve built and packaged. Haven’t tried this feature yet, but it looks very straightforward.
  • Wiki feels a little odd, because you start at a table-based listing of all pages. Beyond that it’s just a basic wiki (with yet another syntax), that’ll do the job.
  • Issues are for tracking bugs and tasks. Haven’t tried this yet, but it looks both straightforward and barebones.
  • Source provides a way to browse the files, view a history of the changes, and check on any clones there may be. Not as fancy as -say- GitHub, but gets the job done.
  • Administer allows you to change just about everything you see in your project, and works quite okay.

The theme should be clear: everything in Google Code is no-nonsense. All important features for code hosting are there though.

Conclusions

This hosting provider is pushing the KISS principle to the max. Google Code gets the job done, but it is very barebones, at times even downright ugly. Great hosting, but it doesn’t leave me “WOWed”. With the same functionality but a more pleasant experience, I think I would prefer CodePlex.