snorremd

Agreed. Makes the Dockerfile much more portable as you don't need build-tooling on the host to make a Docker image of the program. It is also really great when doing CI because you can use the Docker image layer cache to cache build/dev dependencies.

I even suspect Automattic's initial choice to not use React because of the open source license + patents clause was a direct catalyst for Facebook to change the React license, thereby allowing Automattic to use React. Wordpress drives a substantial percentage of the world's websites, so it was probably in Facebook's interest that React was used in project Gutenberg.

Money rules and the CEOs have shareholders to answer to. Making it look good in public is more important than actually taking a stance.

I've built a simple GraphQL server in Clojure using the Lacinia (https://github.com/walmartlabs/lacinia) library. It is about as nice as Apollo to be honest, but you would obviously need to know your way around Clojure.

Lacinia tries to be feature complete (as defined by Apollo Server and GraphQL spec), but obviously does not support everything Apollo does (remote schemas and graphql endpoints for example).

I have not tried any GraphQL server libraries in other languages, so I can't speak for people using C#, Java, or some other language.

I think the tooling around GraphQL is quickly approaching a point where it is better to use GraphQL then REST for client facing services. The fact that you can more precisely define your data needs and don't have to fetch the world, or make multiple round trips, is a big win. The contract a GraphQL schema provides both during development and runtime is also nice.

Træfik works pretty well as an automated https proxy as well: https://traefik.io/ It is still missing a caching feature though, so it might not be a good fit for everyone. It has a Docker backend which works with Docker labels (much the same way the https-portal project uses environment vars).

The Fairphone runs Ubuntu Touch, which is now managed under the UBPorts Foundation. https://ubports.com/ https://devices.ubuntu-touch.io/

I think you hit the nail on the head here. Using PGP/GPG has a lot of upfront cost in learning how to create keys, syncing them, getting them signed, storing them securely, etc. To be absolute certain that the private key is not stolen you even need to create them on an air-gapped machine and use a hardware device like a yubikey when using keys on online machines.

I think in the end most computer users will sacrifice a bit of security for convenience. PGP signature and encryption for email will most likely never take off. Encrypted chat services like Signal seems to have done much better, likely because of how convenient they are to use.

2. After the npmjs.com registry became immutable and npm got lockfiles I feel npm is pretty much there as far as dependency management systems go. I'm not sure if npm shares the cache across projects (like the ~/.m2/repositories folder for maven/gradle/leiningen), but you can get that with the yarn client if saving disk space is important.

Releasing Android One phones is at least a good move if you want to target the purist segment of the Android market. I have previously bought the Nexus phones and around christmas bought a Nokia 8 because HMD put a more or less stock version of Android on it. I much prefer stock Android to the touchwiz business Samsung is doing, at least as it was on my Samsung Galaxy S2 and S3.

It will be interesting to follow Nokia and HMD and I hope they succeed. There are too many phones with subpar custom UIs and menus + crapware that lags one or two major Android versions behind the latest release.

With EU's GDPR (General Data Protection Regulation) looming on the horizon I think Cognitect would do themselves a disservice should they not include excision in their Datomic Cloud platform sooner rather than later.

I like the new multi stage Dockerfile concept in the later Docker versions. It makes it easy to define Dockerfiles that both builds and runs your code, while still separating build and run dependencies. I have used this for both Node and Go projects. As long as the build output is not too spread out in terms of paths copying your build artifacts over to the other Dockerfile stages should not be a big issue.

I really liked this summary, and I recall having gone through some of these stages myself. Discovering BEM and ITCSS made my life a lot better. Even when building React apps now using CSS in JS I still try to maintain BEM style class names. It just feels right.

If Linux people are known for anything it's their love of post-it notes on the side of their screen /s. But yeah. If I wanted a "gorgeous Linux laptop" I would buy a Dell XPS 13". Dell actually puts some work into making their own hardware and they upstream drivers and other stuff so the XPS actually works pretty well with Linux.

Did this not work for Android? I seem to recall that every Android phone manufacturer shipped their own customized Android with different home screens, navigation, widgets, apps, etc. Did not stop consumers from buying the phones. Even today the number of Android phones released with stock Android each year is laughably low.

If your work does not require you to use the proprietary exchange stuff in Outlook I would say that Thunderbird with Enigmail is a really convenient solution for encrypted and signed email. Once set up there is very little overhead involved, and if a recipient's email address is in your local gpg database Enigmail will happily encrypt content by default.

(La)TeX is great when you don't want to manually handle formatting your text. I loved writing LaTeX for the simple reason that I could focus on the content, rather than having to constantly work on the presentation. The markup was simple enough that it did not get in the way.

Barring technical problems I much prefer LaTeX to Word or LibreOffice Writer.

I can't talk for the original poster, but I also deploy containers from Gitlab Registry via Gitlab CI pipelines and just use the standard docker swarm commands. So updating the image digest (version) of a service is as simple as running a shell command in a job in a deploy stage in your gitlab ci pipeline:

docker service update --image <some-image:version> --with-registry-auth <some-service>

Simplest example would be a job definition like this: https://pastebin.com/KsG0cDzR

This job would have to be preceded by building the new docker image you are going to update to of course.

I think Gitlab recommends a 4GB of memory and suspect this helps with caching and thus page loads. In an organizational context it should not be too hard to throw hardware at the problem. In my organization we run a Gitlab instance with at least 20 active users (70 users total) and quite a lot of repositories and usually it runs quite fast. This is on 8GB of memory and 2 cores.

For personal and home use Gitea/Gogs is probably a better choice indeed. As you point out it runs with much fewer resources and as an added bonus it runs as a single go binary which simplifies hosting it tremendously. You could literally just download the binary and run "$ ./gitea web". Gitlab is another beast in that respect, especially if you do not opt for their Omnibus install.

I agree. I too work with a self-hosted Gitlab instance daily, and the UI is neither horribly bad nor horrendously slow. The interaction design and user experience could absolutely use some work, but I feel Gitlab has been moving in the right direction with this.

The navigation is still a bit convoluted, but has gotten better. There are still some issues of nested navigation menus and difficult to find pages. As far as page speed goes it has gotten better and they are actively working on this.

As long as the rate of improvement is as good as it is I see no reason to switch to another solution. Especially seeing how the community edition is free and satisfies basic developer needs.

Gitlab is also the only code repository service which integrates CI jobs and statuses as well as a front-end for a self-hosted docker registry. Absolutely a killer feature!

I think there are no real standard practice or consensus regarding ssh keys and where you need different keys. Some people use one key for each ssh client machine (the machine logged in from), some one key for each ssh server, some use Yubikey to store a single ssh key, etc.

Personally I think one key per client is a good way when not using a hardware security module (e.g. yubikey) as the public key then identifies a unique client machine (e.g. your work laptop). This would help identify which client was breached in an eventual attack. I do think however that I would prefer the Kryptonite solution or using a Yubikey going forward.

Elm is a language, but it also dictates a very specific way of structuring your front-end application. This style is very similar to Redux and other such immutable state -> render -> actions -> reducer -> state flows. I can absolutely see why someone would compare it with front-end frameworks.

Aaah yes. Nintendo Land is the ultimate party game. As far as my Nintendo Wii U purchase goes, I think all the hours of fun me and my friends had with Nintendo Land was worth the asking price alone. Then of course Mario Kart and Super Smash added some extra competitive and skill based fun for when we tired of Nintendo Land. And for some co-operative fun we had a blast with Rayman Legend, perhaps the best Rayman game to date!

I really have no regrets from buying the Wii U. It was such a good couch console!

Another great alternative in the 2FA client space is Authy (free of charge).

Edit: The other commenter actually bothered to look at the code. Scratch my comment.

Edit: I know the parent comments are comparing to Github. I thought that it would be useful to let people know about Gitlab's offering.

It appears Gitlab provides support for custom domains on their hosted Gitlab solution as well as support for different site generators via their Gitlab CI solution. It is probably not as easy to use as Netlify though.

http://docs.gitlab.com/ee/pages/README.html#gitlab-pages-on-...

I think this could be one of the main challenges Elm face in terms of gaining support. I've been playing around with Elm the past week (creating a fun little web app to learn a new language) and the documentation would likely keep some developers from pursuing the language much further. What helped me was familiarity with functional programming via Clojure, and component based web apps with Om and React.

I think the docs could use a chapter on functional programming and how that works in the land of ML languages, and perhaps a few walk through examples of some simple, but not overly simplistic, apps.

So far though I think the language is pretty interesting, but I've yet to do anything really fancy with it.

Sending your password as you type it as a GET request query parameter seems awfully hazardous. As you point out the password will appear in all manner of places, such as HTTP server logs. As the username/email is not included an ops person might not directly know from the GET request alone what user the password belongs to. It is not difficult to imagine however that they have enough info to correlate the IP address of the password strength request with a user.

Indeed. I almost can not contain my excitement.

At my workplace we have 1/5 ratio of users to repositories on our git server. We tend to create separate repositories for modules, applications and even prototypes. In any case if we were to use Github their new pay-per-user model would make more sense for us than the pay-per-repository model.

Do you have a link to the logstash alerting plugin? I'm not familiar with it and I'm interested in alert tools for the elk (and beats) stack.