Pelle Wessman

How to use TypeScript 3.7 to generate declarations from JSDoc

2019-10-07T15:42:27+00:00

Background

While TypeScript for long has supported validating the types in ones javascript files, even reading ones JSDoc-comments, it hasn’t really worked that well for those who in turn wanted to use ones code.

By default TypeScript doesn’t read the JSDoc of any dependencies. One have had to set maxNodeModuleJsDepth to a higher value, which hasn’t been without some issues.

Issues range from having the required depth change over time due to nested modules in node\_modules, making it hard to guarantee that types has been read, and picking up weird JSDoc comments from other packages – JSDoc comments that has never been tested for correctness.

So, what about TypeScript 3.7? It introduces a way to create a type definition file from your JSDoc definitions. I decided to try it out on a project.

How-to

This is how I added it to a project which publishes a single index.js file, bunyan-adaptor:

1. Create a new tsconfig file

Add a new tsconfig.json with the sole purpose of generating your declaration. This way you can avoid getting declarations generated for tests and such.

I added a declaration.tsconfig.json containing:

{
  "extends": "./tsconfig",
  "exclude": [
    "test/**/*.js"
  ],
  "compilerOptions": {
    "declaration": true,
    "noEmit": false,
    "emitDeclarationOnly": true
  }
}

2. Add a npm script for generating the declaration

"declaration:build": "rm -f index.d.ts && tsc -p declaration.tsconfig.json",

3. (optional) Add a npm script for ensuring your declaration has been committed

"declaration:check": "git diff --exit-code -- index.d.ts",

4. (optional) Add a prepublishOnly npm script

"prepublishOnly": "npm run --silent declaration:build && npm run --silent declaration:check",

Or simpler, with the use of npm-run-all:

"prepublishOnly": "run-s declaration:*",

5. Profit / Party / 🦄 / 🤳

However you want to celebrate: This is the moment.

Run npm run declaration:build, commit the resulting index.d.ts and publish your module!

Note: Visual Studio Code could/will complain about your generated type declaration unless you tell it to use TypeScript 3.7.

Tell it by running the TypeScript: Select TypeScript Version... command when in eg. the type declaration file.

När tågtrafiken kollapsar – vem fyller upp?

2017-06-28T15:41:00+00:00

Tågtrafiken är i haveri. Vi kan swipea hem oss några häftiga burritos genom ett cykelbud, boka taxis genom några enkla små gester – men tågen? De står alltjämt still.

Startupvärldens delningsekonomi löser det jag inte visste jag behövde ha löst, men det jag verkligen behöver få löst – som den grundläggande infrastrukturen som tar mig från södra Skåne till norra eller än längre bort – där lyser den med sin frånvaro.

Varför?

Vill ingen betala för en fungerande infrastruktur?

Vissa politiker skulle hävda att vi hellre vill ha lägre skatt och optimerade upphandlingar än tåg som rullar enligt tidtabell, men när man sitter och ska till jobb, möte eller bara är helt slut efter en jobbdag och bara vill hem till soffan innan man fullkomligt kollapsar – ja då är vi få som bryr oss om de där få tiondels procenten i skatt eller den där hyperoptimerade upphandlingen – vinsten i att komma fram vore alla gånger än större.

Att betala för en infrastruktur man kan lita på? Ja tack.

Att det kommer att ske via statlig politik? Verkar tveksamt.

Kan inte startupsen hjälpa oss? Om jag vill vara garanterad att komma från punkt A till punkt B trots den miserabla infrastruktur vi sitter med just nu? Om jag vill försäkra mig om att komma fram när jag bör komma fram? Om jag är beredd att betala för det? Kan där då inte finnas en försäkring för det?

En försäkring som går utöver det som Skånetrafiken ger. En försäkring som ser till att driva in alla de där ersättingarna som Skånetrafiken blir skyldig mig. En försäkring som fixar avtal och samordnar så att när allting kollapsar, då finns den där – en Plan B – en buss, en taxi – som bortom vad Skånetrafiken lyckas ordna ser till att jag kommer dit jag bör komma. Som en IKEA buss, fast för alla oss andra.

En försäkringsstartup som fyller igen för en kollapsad infrastruktur och ser till att de lösningar som politikerna inte förmår ta fram ändå finns där för de som behöver den.

Skulle det funka?

Det borde vara något som staten borde lösa. Tills dess vore det dock trevligt om någon annan kunde kliva in. Även om det då innebär att lösningen bara kommer vara tillgänglig för dem med plånbok nog att betala för den.

(En brainstorm i frustration över den nuvarande situationen där tågtrafiken i princip dagligen dras med allvarliga problem som ofta resulterar i vad som närmast kan sägas vara total kollaps – och det utan tecken på bättring i närtid)

3 tricks to better handle npm modules

2016-07-05T17:10:00+00:00

Developing with npm modules isn’t just installing modules and then updating them. In a team environment you might not even know when a new module should be installed or when its version requirement has changed. This can cause lots of weird unexpected behaviors when the installed modules doesn’t match the expectations of the app – and that annoys and is a waste of time.

Here I’ll give you three tricks to avoid that. Tricks which I’ve begun to use over the years and which we’re currently using at my latest project, the development of the new sites for Sydsvenskan and HD.

1. Verify installed versions against package.json

When rapidly developing a new site, establishing the basic features etc, new modules gets added quite a lot. Often after a rebase one realize that one is missing a module after ones nodemon process suddenly crash with some unexpected weird error.

I created installed-check to solve that. To have a script I could run to check if my installed modules still fulfilled the requirements set out by the package.json or whether it was time to install some more. All checked locally, without any slow network lookups or such.

If any module were missing or were outside the version requirements it would exit with an error.

I then hooked that script into my npm test script and into husky (at postapplypatch and postmerge) so that whenever I pulled down new code or ran my tests it verified that my installation was up to date.

With that in place everyone in the team could stop worry about whether they were missing a module locally and we could all stop wasting time debugging issues that were due to changes in the package.json requirements. Happy developers!

2. Verify that package.json is in sync with actual module usage

While tests may pass just fine locally, if one doesn’t commit all the dependency requirements then it’s hard for them to pass anywhere else.

Likewise refactored code may work just fine, but one may not have realized that a removed require() was the very last one for a given module.

Therefore I always run dependency-check (which I now co-maintain) in my npm test. To ensure that uncommitted dependencies are caught early and that no extra modules are kept around and weighing down the project after they are no longer in use.

I also make npm test run before code is pushed remotely by setting up a prepush git hook using husky. That way neither I or anyone else in the team can accidentally push code with any such mistakes. (I’ve found prepush to work better for this than precommit – more pragmatic, with happier developers as a result)

3. Verify engine requirements of installed modules

How do you express what versions of node.js your library supports? There’s the engines field in package.json for that:

"engines": {
  "node": ">=5.0.0"
}

Simple. You know what engine you support and you politely tell others so that they easily can find out as well.

But how do you detect when others update their requirements and how do you avoid that you get dependencies that have stricter engine requirements than you yourself have? Surely there must be able to verify that automatically?

Check out the just released 2.0.0 version of installed-check: It has a new optional flag, --engine-check, that makes it also check the engine requirements of all of the installed dependencies.

If the engine requirements of any installed dependencies doesn’t match yours, then an error will be returned along with a suggestion of a stricter engine requirement whenever possible.

By running that in your npm test you can easily early detect whenever an engine requirement change and either avoid the change altogether or move along with it and release a new major version yourself with the new stricter engine requirements. (Changed engine requirements are always to be considered a breaking change, which requires a new major version according to Semantic Versioning)

Only gotcha with this approach is that not all modules explicitly define their engine requirements in their package.json. By default installed-check ignores any such modules and doesn’t treat undefined engine requirements as an error. By setting either or both of the --verbose and --strict flags one can make it warn or throw errors whenever it encounters such a module though.

Example: Run all the tricks

Install the modules:

npm install --save-dev installed-check
npm install --save-dev dependency-check
npm install --save-dev husky

Set them up to run:

{
  "scripts": {
    "test": "installed-check -e && dependency-check . && dependency-check . --extra --no-dev",
    "prepush": "npm test",
    "postapplypatch": "installed-check -e",
    "postmerge": "installed-check -e"
  }
}

Then profit from a more solid dependency workflow and a more happy development team!

Experts don’t change the world, society does

2016-03-13T13:50:00+00:00

The expert. The pinnacle of knowledge within a field. The Einstein. The one who pushes the boundaries of humanities to new heights. The true revolutionary. The one everyone wants to be. The one everyone strives to become.

Or?

The expert truly knows a lot. But the expert mostly knows a lot about something in particular. It understands a field very well and knows how to solve problems and push things forward within that field.

But what about other fields? Does the expert also necessarily knows a lot about the other fields that it interacts with? Is the expert also an expert in integrating it’s solution into the wider context of society?

There’s many types of knowledge. There’s everything from the deep knowledge within a narrow field to the wider, more shallow knowledge across a range of fields. Any kind on it’s own doesn’t change the world, but when they interface with each other and leverages one another, that’s when true change can occur.

By worshipping the expert, the specialist, as the one to change the world, we neglect the necessity of, and the power that comes with, a wider understanding of knowledge.

It’s when society works together to tackle challenges as one, and when the knowledge of a wide range of disciplines and kinds are combined, that true powerful change is achieved.

When through the power of generalists the knowledge of experts are combined. That’s when society truly shines.

My 2015 in Summary

2016-03-13T10:00:00+00:00

2016 is in full swing and it’s long overdue to take a look back at the past year and what happened then. This is the final part of this four part series of posts about 2015.

tl;dr

The year started out at Bloglovin, but I later left and now I freelance. Throughout I built some cool stuff for both Bloglovin (push, better images, smarter feed) and the IndieWeb (publishing to Jekyll blogs from eg. iOS etc) and now I’m all occupied building cool stuff as a freelancer.

A list of all new projects 2015

Metadataparser – Node.js module, Bloglovin-related of which I currently have a personal fork
Promised Retry – Node.js module
PG Pubsub – Node.js module
Fetch Politely – Node.js module
Micropub Express – Node.js module, IndieWeb-related
Format Microformat – Node.js module, IndieWeb-related
GitHub Publish – Node.js module
and some other projects that I have yet to polish some more on as well as eg. the above mentioned workflows for Workflow.app and Editorial.app that isn’t really standalone projects of their own

A list of updated projects 2015

Lintlovin – Node.js module, a personal fork of mine which is upgraded to eg. use ESLint
A WebMention Endpoint – hosted service written in Node.js
Connect PG Simple – Node.js module – probably my smallest and most popular project with certainly the highest amount of contributors (GitHub currently says 8 other persons have contributed to it)
and some other projects as well as a bunch of PR:s that’s been contributed to a bunch of projects – such as Dependency Check.

A list of all posts in this series

Part 1: My 2015 in Startup
Part 2: My 2015 in IndieWeb
Part 3: My 2015 in Freelance
and this post as the final part

My 2015 in IndieWeb

2016-03-12T15:55:00+00:00

2016 is in full swing and it’s long overdue to take a look back at the past year and what happened then. This is part two of four in a series of posts about 2015.

The summer

For the remainder of the summer, after I had left Bloglovin, I decided to take a long vacation, or as Chris Messina puts it: a ”funemployment”. Reading books in the sun during the day and coding IndieWeb in the nights.

Lots of interesting IndieWeb experiments therefore happened during the summer, that pushed me closer to being able to have a more complete IndieWeb experience at this site.

Micropub – the missing piece

First and largest of those experiments was my decision to finally tackle the main challenge I have had in participating in the Indieweb: The fact that this blog is a static Jekyll based GitHub Pages site.

The static nature of course means that I can’t do anything dynamic on the server side and with the ethos in the IndieWeb world (and beyond) being that websites should be curlable it has been a challenge to add anything but non-original content such as WebMentions to it.

I therefore decided to look into the feasibility of making a separate service which could accept instructions to add or modify original content on my site and perform the commits to my site that it needed to carry out those instructions.

With Micropub becoming the standard API within the IndieWeb community for such type of instructions I went on to create a bridge between that and the GitHub CRUD API. I created three different Node.js modules through which I got an interface for Micropub requests, a transformation of it into the files I need to commit and a simple module for commiting those to my repository.

By connecting those I got a service with which I could finally accept posts to my blog from tools like OwnYourGram and Quill. I even got support for uploading images and videos that are part of those posts.

My Jekyll theme also got extended so that it could present the now much more rich posts in an appropriate way, through some more complex templating, and I also added two new lists on my site, Links and Social, so any non-blog content had somewhere to go.

I’ve yet to polish the glue that binds the three modules into a service and the Jekyll templates that renders the posts. When I have they will be released as their own projects as well.

iOS – the dogfeeding

With the publishing working I went on to look for useful ways of using it. Since I had been intrigued by the Instapaper annotations flow that Federico of MacStories had described for the Editorial app in some articles I couldn’t resist trying to adapt it to my new Micropub endpoint so that I could start publishing my own annotations in an IndieWeb selfdogfeeding way.

That meant I had to create a Micropub client for the Editorial app, but thanks to the amazing Python integration that Editorial.app has, I pretty soon had a rough version of such a client up an running.

I recorded some screencasts showing the Editorial flows in practise. Here’s one for publishing said Instapaper annotations to my Links section on my blog (sorry for the silent sound):

It uses the three Editorial workflows: Micropub, IndieAuth and optionally, if one wants to re-authenticate, IndieAuth Deauthorize.

I later extended my main flow with more metadata + added a flow for replying to posts from within a browser through a new Workflow.app workflow and Editorial workflow. Here’s an updated screencast showing that in practice:

I also created a Workflow.app workflow for publishing a bookmark (with an optional quote from the selection on a page in a browser), reusing the same IndieAction Editorial workflow as the reply flow did.

So – from at the start of the summer not being able to programmatically publish anything to my blog I could at the end of the summer both publish posts with images and video and publish posts from iOS. I could even reply to posts from within a browser. That’s pretty cool. Happy that I had time to finally overcome the obstacle and imagining that it can open up some new possibilities going forward.

My blog – nearly IndieWeb ready

With Micropub support done my blog now nearly supports all the most important aspects of an IndieWeb:ish site. All that’s missing before I feel that I can say that it is fully IndieWeb ready is automatic WebMention sending. That has proved a bit problematic for static sites as there’s often a delay between publishing something and it being published, as the site has to be built. One therefore has to wait with the Webmention pinging until one knows that the update has actually been published., which requires some special mechanisms. I have some ideas for that as well and some tools have also started to emerge within the IndieWeb community so I hope that in 2016 I will have that little last piece of the puzzle solved.

Webmentions – a status update

Micropub wasn’t the only IndieWeb project I worked on in 2015. I of course also worked on my Webmentions project which for long has been my main IndieWeb project.

In 2015 I released a bunch of new features and tweaks to my Webmention project, such as:

At the very beginning of the year a new experimental embed, ”cutting-edge”, was introduced to allow for new UI-additions without breaking existing embeds. With the initial release a facepiles was added and all interactions such as like and repost was moved there.
Basic support for updates as well as some deletes of mentions was finally introduced – fully realtime for some embeds. So now any awkward misspellings etc. can be quickly and swiftly fixed. Full delete support is being tracked in issue #5.
I extracted the PG Pubsub from the realtime solution and launched it as a separate module so it can help fulfill Postgres Pubsub needs in other projects as well. As part of that I also launched Promised Retry as a generic Promised based wrapper and retry mechanism that ensures that something like a working database connection is always returned to the caller, even if the original connection has been lost and a retry has to be made.
I also extracted the code responsible for ensuring that all web pages fetched are fetched ”politely” (rate limited) and combined that with an optional robots.txt mechanism extracted from my relspider project and launched that as a combined module called Fetch Politely so that ultimately both my projects as well as those of others can utilize the same basic polite fetching mechanics. I also added a new optional database backend to the module, which I began using in the Webmentions project to ensure that any throttled fetches was persisted and shared beyond the life of a single instance, which in turn made me relax the mechanisms around eventually rejecting source URL:s from a domain that’s flooded with requests.
As with most of my projects I moved to iojs and then later Node.js 4.x and 5.x to get newer features like arrow functions and native Promises. I still don’t do eg. Babel, especially not server side.
In the later part of the year yet I added yet another new embed option. This one solved the curlability problem of the original two embeds by moving to a progressively enhanced curlable link (identified by experimental microformat class ”u-responses”). This enabled eg. evenntually supporting Salmentions. As a consequence of rendering more things server side due to this I also decided to move the project to my Tema theme engine to get an improved server side templating solution that’s also shared with my other projects and can eg. enable new themes to be created for the project, which opens up some new possibilities.
A full Salmentions flow was also added, but not released. It receives comments from downstream, presents them and repings them upstream. As part of this I again stumbled upon the amazingness of Postgres by being able to recursively fetch the comment tree, no matter how deep it was, through the use of ”WITH RECURSIVE”. The current implementation of Salmentions is yet a bit too optimistic to be released. It repings upstream no matter if a mention has changed or not, which means quite some excessive pings and maube even in the worst case scenario an infinite sequence of circular pings. I therefore plan to add some kind of check whether a post has been updated or not before launch. That and other Salmentions issues is being tracked in issue #21.
As part of the Salmentions feature I also moved the parsing of pages to an extendable fork of the Metadataparser module that I had made at Bloglovin previously in the year. But with added in Microformats parsing for this project of coruse.

All changes in my Webmention project in 2015 can be found in its changelog and one can also subscribe to releases to get notified about changes as they are released.

The future

In 2016 I plan to wrap up my Micropub setup and release all of the code related to it as reusable compontents. I also hope to finalize Salmentions support in my Webmention project and to get my blog to actually start sending Webmentions itself so that the full circle of Reply -> Notification -> Reply starts to work for me.

In the nearest future I will do a presentation on the future of the social web in general and IndieWeb in particular on March 23 at Foo Café here in my hometown of Malmö.

I also hope to be able to attend some of the IndieWebCamps that are coming up, such as the Nuremburg and Düsseldorf ones.

Next part

I’ll soon publish the remaining parts of this serious of four posts about my 2015.

My 2015 in Startup

2016-03-10T22:30:00+00:00

2016 is in full swing and it’s long overdue to take a look back at the past year and what happened then. This is part one of four in a series of posts about 2015.

The start

2015 started out in the startup world. I was still part of the Bloglovin and we were finally getting ready to launch some of the work of me and my closest colleagues.

Push and Facebook mimicking

For me my first feature to launch was push notifications. When I first joined Bloglovin I was tasked with building the backend that handled our users’ notification subscriptions across all of their devices and ensuring that messages was routed correctly whenever any of our backends wanted to notify a user about something. We initially launched on iOS with follow notifications to try the systems out and then later on added notifications for new posts as well.

Next major feature of mine to launch was an improved metadata fetching for the blog posts. The platform featured a lot of gorgeus images and of course we wanted to present them the best way possible and I wanted to try and utilize the very same metadata that Facebook spearheaded sites to achieve that for us. That meant going beyond the metadata of the RSS feeds and pull down the actual blog posts, which were quite a few, and pull out that open graph data from them. Me and awesome devops Love did a successful experiment with utilizing Amazon Lambda to launch a fetching at that scale and amazingly saw it scale fairly easily to the full firehose of all new blog posts imported into Bloglovin (and that’s not few). Lambda really left an impression on me – it’s a cloud service that really deliveres on the promises of the cloud and is certainly something I want to return to in the future. After we have had the parser running for a while we also open sourced the very code behind it, metadata parser, to make it easier for others to also make use of that same data so that all of us could have better metadata to show to our users.

While working on the metadata fetching project we also had a great gathering of the entire Bloglovin team in Stockholm where lots of amazing ideas were discussed – some truly inspirational days with great feedback and some great shout outs from members of the team. When working on a mostly remote team days like these are extra joyful.

Widgets and smart feeds

With spring arriving two more projects came about to launch. First out was a new platform for interactive widgets. I created a structure that enabled the creation of a bunch of new javascript widgets and first out to launch was two follow widgets – one where a user could follow a blog in a single click one and another one where they could follow through e-mail. All packaged up according to modern best practises for social media widgets and easily addable by bloggers to their blogs – a way to bridge the gap between Bloglovin the platform and the blogs of the blogosphere.

Then came the smart feed. Me and my colleague of the Malmö office, Hugo, were tasked with creating a new API endpoint that could weave additional kinds of content, eg. recommendations, into Bloglovin’s classic blog post feed. Through close cooperation with the iOS team and some great feedback from Jared and others we designed what I believe was a pretty solid and flexible API that could scale to most feature requirements and have lots of room for future experimentation – all while still remaning compatible with and presenting a good experience for all those who doesn’t update their apps the second a new version comes out. It was a great experience to have to design such a flexible API for an environment such as iOS with the different limitations it has compared to the web and the adaptions one have to make to accomodate for that, especially when it comes to supporting legacy versions of an application – something one can often avoid in regular web development work, perhaps to the harm of the API design of those.

The departure

Then came summer and it became time for the Skåne team of Bloglovin to leave. Each one of us found we wanted to move on so as summer got closer and closer more and more of us left. For me it had become ever more apparent that me and Bloglovin had different visions on how to move ahead and I then felt it was best for us to part ways. So at the end of June I left the company and followed the example of Simon, who had left just before, and started to freelance (Simon later on got an awesome opportunity to join Filibaba where he’s now part of producing amazing vegetarian recipe apps – exciting stuffs!), while Hugo around the same time decided to join up with the local major newspaper HD-Sydsvenskan (where also he is creating some rather amazing, although so far less visible, stuff – Go-driven newspaper will be the thing of 2016!).

Next part

I’ll soon publish part two in this series of four post about my 2015 which will take a look at what happened in the IndieWeb world.

My 2015 in Freelance

2016-01-03T10:00:00+00:00

2016 is in full swing and it’s long overdue to take a look back at the past year and what happened then. This is part two of four in a series of posts about 2015.

The start

Bloglovin and IndieWeb aside, after the funemployment of the summer the projects started to arrive in the autumn and now I’ve got plenty to do with lots of freelancing projects of a very varying nature and am gaining new experiences by the day and evaluating, planning and thinking about the upcoming year and what shape and in what direction I will take my freelancing then.

My latest project, which is still an ongoing one with many additions and tweaks to come, is the site for this year’s The Conference which was created with Node.js, Heroku, Stripe, Sass, Browserify, some vanilla JS etc. and which sold a fourth of all of the tickets in just three days without a hiccup and before any speakers had been announced. More tweaks will come and speakers and programs will be added.

As for this year it will start out by rejoining some former colleagues on an interesting Malmö based project until February and after that perhaps a new office at Malmö Coworking. The plans are still not set for the rest of the spring and summer so there’s still a possibility to hire me for whatever crazy project or sweet creation one would want my help or input on. We can always grab a coffee and discuss the possibilities, so send me an email at [email protected]">[email protected] if you think you have an interesting opportunity – tiny or large.

That’s 2015. Quite a lot happened there. And this is 2016. And even more will happen here. But to end things – here’s a full list of the open source projects of mine that I’ve created or updated during the year:

2015 in review

2016-01-03T10:00:00+00:00

A new year has come and it’s time to say good bye to an eventful year by taking a look back at it.

tl;dr

Startup

2015 started out in the startup world. When it entered the scene I was still part of Bloglovin and we were getting ready to launch a lot of the stuff me and my closest colleagues had been working on.

My first feature to launch was push notifications, of which I was tasked with building the backend that was the middleman between devices that were to receive notifications and our other backends that wanted to notify a user about something.

Then the launches moved on to improved metadata fetching for blog posts – something which was to enable eg. better images on Bloglovin by utilizing the very same metadata that eg. Facebook uses. Me and the awesome devops Love on this also did a successful experiment with Amazon Lambda and thus saw it scale to all of Bloglovins imported blog posts with ease – a cloud service that really delivered on the promises of the cloud and something I definitely want to return to in the future. Later on we also open sourced the very code behind the metadata parser.

In the midst of the metadata fetching project we also had a terrific gathering of the entire Bloglovin team in Stockholm where lots of amazing ideas were discussed – some truly inspirational days.

When winter then turned spring and the summer started to approaching two other projects launched. First out was new interactive widgets – a platform that enabled the easy embedding of javascripts widgets on peoples own blogs so that one could eg. follow a blog on Bloglovin through a single click. After that came the smart feed that where I and Hugo of the Malmö office were tasked with creating a new API endpoint that could weave any kind of additional content or recommendations into the classic blog post feed. Through close cooperation with the iOS team and some great feedback from Jared and others we came up with a very solid and flexible API and backend that could scale to any feature requirements, leave the room open for lots of experimentation while still preserving good experience for all those weird people who doesn’t update their app the second a new version comes out. (Native apps and the challenges in pushing updates to code really puts a different perspective on backend development – and makes for some interesting situations and fun stories. A great experience to have.)

As summer arrived we all in the Skåne team of Bloglovin decided it was time to move on. For me Bloglovin wanted to move in a different direction than I did. After first having moved to a new apartment I followed the example of Simon and decided to freelance (Simon later got the awesome opportunity to join Filibaba where he now produces amazing apps with vegetarian recipes, while Hugo on the other hand went on to HD-Sydsvenskan where he apparently is also creating some rather amazing, although less visible, things).

IndieWeb

So I left Bloglovin at the end of June and entered a few months of vacation/”funemployment” (following the example of the excellent Chris Messina) while waiting for the Swedish business world to get back from vacation – and what better way to spend a ”funemployment” than to read books in the sun and code IndieWeb in the dark?

The months after Bloglovin saw some interesting IndieWeb experiments. I decided to finally tackle one of the major problems I’ve been having in the IndieWeb problem: The fact that my blog is a static GitHub Pages hosted Jekyll site – something that makes it hard to do all of the dynamic awesomeness of eg. Micropub. The simple solution would be to just abandon the staticness, but I really like Jekyll and how it enables me to focus on just content and markup and nothing but that. I also solved WebMention for static sites 1,5 years before so surely Micropub could also be solved?

I decided that it would be my summer project – enabling myself to publish to my static GitHub Pages hosted Jekyll blog through a Micropub API. And three open sourced modules later I had it up and running. Through the Micropub Express, Format Microformat and GitHub Publish modules and some minor glue in between the three I could publish posts to my blog through tools like OwnYourGram and Quill and they would be presented in the appropriate way through some more complex templating in my blog and possibly presented in one of the two new lists on my site, Links and Social. I’ve yet to polish the glue and the templates so that those can be released separately as well though.

When I had the publishing part working I also wanted to find useful ways to publish to it and since the IndieWeb is all about selfdogfeeding I couldn’t resist trying to copy the Instapaper annotations flow that Federico of MacStories described for the Editorial app in two articles – so I had to try to create a Micropub flow for the Editorial app as well – and I succeeded (that funemployment thing – very productive) although it’s still a bit rough.

A screencast of the Editorial flow for publishing Instapaper annotations to the Links section of my blog (sorry for the silent sound):

It uses the three Editorial workflows: Micropub, IndieAuth and optionally IndieAuth Deauthorize.

I later extended it with more metadata + a Workflow.app workflow and Editorial workflow for replying to posts from within a browser. Here’s an updated screencast showing that:

I also made a Workflow.app workflow for publishing a bookmark with an optional quote from the selection on a page in a browser – it uses the same IndieAction Editorial workflow as the reply one did.

So, I can now publish to my static blog from iOS – that’s pretty cool – happy to have had time this year to overcome that obstacle.

Now my blog supports nearly all the aspects of an IndieWeb:ish site – all I want to add before I say that it is fully IndieWeb:ish is automatic WebMention sending (something that’s a bit problematic for static sites as there’s often a build delay between publishing something and it being published, which means one has to wait with the pinging until one knows something has been published successfully. I have some ideas on plans on that as well though – that’s in the same spirit as my other solutions – so 2016 will likely see that little last piece of the puzzle solved).

In other IndieWeb news during the year: Not only did I focus on the new Micropub-related projects, but I of course also released some updates to my WebMentions project. All changes can be found in the changelog or can be subscribed to, but to summarize the most major changes:

At the very beginning of the year a new experimental embed, ”cutting-edge”, was introduced to allow for UI-additions and with it a facepile for showing interactions such as like and repost was introduced.
Basic support for updates as well as some deletes of mentions was introduced – this also happens in realtime in some of the embeds.
The PG Pubsub module was extracted from the underlying realtime solution and launched as a separate module for any Postgres Pubsub needs. As part of that also Promised Retry was launched to provide for a Promised based mechanism to ensure that one always receives a database connection when asking for one and that proper retries are made when the connection is lost or can’t be established.
The code responsible for ensuring that all web pages fetched as part of the endpoint are fetched ”politely” (rate limited) was extracted as Fetch Politely and extended with an optional robots.txt mechanism from my relspider so that ultimately both projects + other similar projects can share the same basic mechanism. Also added an optional database backend to that module which introduced persistence of throttled items across instances for the WebMentions project which in turn made me relax the limit of how many throttled items the endpoint accepted before returning errors.
As with most of my projects I moved to iojs and then later Node.js 4.x and now 5.x to get newer features like Promises and arrow functions natively. I still don’t do eg. Babel, especially not server side.
In the later part of the year yet another embed solution was created – one which solved the curlability problem of the original embeds by moving to progressively enhance an existing link (marked up with the experimental ”u-responses” class) rather than inserting WebMentions straight into the page. This was a precursor to Salmentions support. As part of the work I also moved the WebMention project to use my Tema theming engine as I then felt a need for a server side templating solution and I preferred to reuse the same solution as on my other projects and the themability features that comes with it adds some cool new possibilities.
Not yet released, but added a full Salmentions flow that receives comments from downstream, presents them and repings them upstream. As part of this I yet again discovered the amazingness of Postgres by recursively fetching an infinitely deep comment tree through the use of ”WITH RECURSIVE”. Also as part of this feature extended and moved the parsing mechanism to an extendable fork of the Bloglovin Metadataparser module that I created previously in the year and extended it with Microformats parsing for this project. The current Salmentions implementation is a bit too optimistic though, it repings upstream no matter if a comment has changed or not which can probably even result in infinite repingings – so some kind of check whether a post has been updated or not, perhaps even a pessimistic such, remains before launch and is being tracked in #21.
and throughout the year did bug fixes and improvements to the underlying system

Freelancing

A list of all new projects 2015

Metadataparser – Node.js module, Bloglovin-related of which I currently have a personal fork
Promised Retry – Node.js module
PG Pubsub – Node.js module
Fetch Politely – Node.js module
Micropub Express – Node.js module, IndieWeb-related
Format Microformat – Node.js module, IndieWeb-related
GitHub Publish – Node.js module
and some other projects that I have yet to polish some more on as well as eg. the above mentioned workflows for Workflow.app and Editorial.app that isn’t really standalone projects of their own

A list of updated projects 2015

Lintlovin – Node.js module, a personal fork of mine which is upgraded to eg. use ESLint
A WebMention Endpoint – hosted service written in Node.js
Connect PG Simple – Node.js module – probably my smallest and most popular project with certainly the highest amount of contributors (GitHub currently says 8 other persons have contributed to it)
and some other projects as well as a bunch of PR:s that’s been contributed to a bunch of projects – such as Dependency Check.

Den oberoende sociala webben 2015

2015-09-18T19:00:00+00:00

Sociala medier. Synonymt med Facebook, Twitter, Instagram. Vad händer när en av dem försvinner? Är det game over då? Jaiku i repris, fast denna gång utan livlina?

Framtiden för sociala medier kan låta dyster. Om de inte läggs ner helt så kan de ju i alla fall ha moraliska frågetecken kring konst, aktivism eller annat. Men i det fördolda har många länge ställt frågan: Om webben är öppen, varför måste det sociala vara stängt? Och nu börjar det röra sig där.

Att ställa en fråga har alltid varit bra. Att fixa en lösning har ofta varit bättre. Att fixa lösningar har dock inte lyckats lika bra som alla frågor som ställts. Många fina lösningar har tänkts ut, men de flesta har ignorerat den verklighet och det sammanhang vi lever i och framförallt den nätverkseffekt som ger de sociala medierna sitt största värde idag. Men – turligt nog rättar sig inte alla i det ledet och nu börjar det bli spännande.

IndieWebCamp startade 2010 av Aaron Parecki och Tantek Çelik för att de ville se ett annat fokus än det tanke-centrerade, små-akademiska som varit innan. Ett fokus på att skapa snarare än att prata. Ett fokus på att lösa ens egna problem. Och ett fokus på att äga sin egna data i praktiken, inte bara i teorin. Sedan dess har många anslutit sig och flertalet verktyg och tjänster växt fram – IndieWebben har blivit en rörelse.

Idag är i princip alla komponenter redo för att kunna återföra det som en gång i tiden kallades för mikrobloggar tillbaka till sina bloggrötter. Och det utan att bryta med de stora sociala medierna så som många tidigare lösningar krävt. Det finns de som redan gör så idag, bl.a. grundarna av IndieWebCamp, och även min blogg är väl nästan redo att sälla sig dit.

Så – idag kan man alltså i princip både vara sin egen och vara en del i de stora sociala plattformarna – och de skarpa hörnen som ännu finns blir mer och mer rundade för var dag som går.

För att vara mer konkret så har det ur IndieWeb-rörelsen kommit möjligheter att:

Ta emot replies, likes m.m. på sina inlägg direkt från andra bloggar via en teknik som kallas WebMentions. Bl.a. jag själv tillhandahåller en Disqus-liknande tjänst som gör det lätt att ta emot sådana reaktioner i realtid på vilken sida som helst – något flera har valt att nyttja.
Posta poster från ens egna sajt till existerande sociala medier via vad som kallas POSSE (Publish (on your) Own Site, Syndicate Elsewhere) och få tillbaka reaktioner därifrån som WebMentions genom tjänster såsom Brid.gy – så att de som ännu hänger kvar i klassiska sociala medier kan fortsatt vara lika delaktiga som de är idag.
Svara på inlägg direkt från någon annans sajt genom Webactions och Indie-Config (se mitt tidigare inlägg). Sådana knappar finns t.ex. på denna posten, men i nuläget har jag inte själv kopplat in reaktioner från Twitter så de kommentarer som postas via Twitter syns tyvärr inte här ännu.
Posta nytt innehåll via ett standardiserat API, Micropub. Det möjliggör t.ex. för mobila klienter (har spelat in en screencast som visar en prototyp på ett flöde som man kan få till redan idag) liksom för automatisk import från existerande medier såsom från Instagram via OwnYourGram. Mitt nuvarande IndieWeb-projekt som i princip är klart exponerar till och med ett sådant API för statiska Jekyll-sajter på GitHub Pages eftersom jag själv kör en sådan. Kommer blogga mer om det längre fram.
En inloggningsmekanism, IndieAuth, som gör att man kan logga in på alla olika tjänster med sin egna sajt och ge tillgång till olika saker där – likt ”Sign in with Twitter” och liknande – fast som allt annat inom IndieWebben helt distribuerat.
Olika läsare för oberoende innehåll om man vill följa dem och interagera med dem oberoende av existerande medier. Vissa av dessa kan också användas för att interagera med poster och publicera nya vilket i princip gör dem till fullgoda sociala medie-alternativ, med enda skillnaden att alla poster och aktiviteter postas på individuella och helt separata bloggar. Hittills efterliknar tyvärr de flesta sådana läsarna RSS-läsare snarare än sociala medier, men det är mer av en designutmaning än en teknisk utmaning – grunden är densamma oavsett.

Så I stort sett täcker IndieWebben idag åtminstone allt det en plattform som Twitter behöver kunna – och i stort så kan det göras lika smidigt där som det kan på Twitter.

IndieWeb-rörelsen tog dessutom för någon månad sedan och demonstrerade att de kunde genomföra det så kallade SWAT0-testet som är tänkt att vara ett implementationsoberoende test för att visa att ens tjänster distribuerat klarar av att hantera ett måttligt vanligt sociala medier scenario. Tre aktörer med tre olika implementationer deltog i testet och många fler är på gång att kunna demonstrera detsamma, däribland min egna WebMentions-tjänst som nästan har alla bitar på plats.

Så – vad är slutsatsen med allt detta Indie-hit och Indie-dit? Är det inte ändå till syvende och sist bara massa tekniknördar som flippar loss med sina älskade tekniska termer och som saknar varje liten verklighetsförankring man skulle kunna önska? Nej. Denna gången är det annorlunda. Denna gången är fokus på verkstad. Denna gången bevisas att något funkar innan det dokumenteras som en standard. Denna gången löser något ett verkligt behov före att det lyfts fram som frälsaren för alla de andra. Ingen IndieWeb-standard har kommit till utan att också ha haft en fungerade använd implementation i verkligheten från dag ett.

Eftersom fokuset varit på verkstad så har indiewebben byggts för att kunna samexistera med dagens sociala webb och i takt med att de stora sociala mediernas roll därmed så sakteliga kan minska i takt med att oberoende lösningar börjar användas så kan ett gradvis överflyttande ske i takt med att allt fler upptäcker fördelarna – ett hyfsat realistiskt scenario alltså till skillnad mot många tidigare drömmar.

Allt är såklart inte guld och gröna skogar ännu. Det finns fortfarande svårigheter kvar och alla varken kan, bör eller kommer att byta över idag eller imorgon. Men det viktiga är: Det finns en lovande start som det är lätt att börja nosa på och i takt med att allt fler nosar så fås allt mer erfarenhet och med mer erfarenhet byggs än bättre upplevelser och plötsligt finns där en klar väg framåt (en väg som dessutom öppnar för många nya spännande innovationer inom området).

Så när Twitter kanske så småningom försvinner så kanske den inte blir ett nytt Jaiku. För då kanske vi flyttat tillbaka hem. Vi kanske då har vår bas på den egna bloggen igen. Och då kan ingen någonsin stänga ner oss igen. Då är vi våra egna och ingen annans. Oberoende på riktigt. Så som webben är ment att vara.