Xebia Blog
blog.xebia.com · Company blog · on HN since 2008
Xebia, a software consultancy, publishes engineering posts on Docker, Scala, Swift, microservices, and related tooling.
What HN saysHN commenters cite it for its small Docker container guide and for points on Swift breaking changes, HTTP2 server push, and Docker persistence.
32HN people shared it
8linked it in comments
30stories submitted
124story points
9 years agolast shared
2008people per year2026
Most-shared posts
- 1Create the Smallest Possible Docker Container3 people · 3 points · first shared 2014 · discussion on HN
- 2The monolithic front end in the microservices architecture2 people · 3 points · first shared 2015 · discussion on HN
- 3How to Create the Smallest Possible Docker Container of Any Image2 people · 1 points · first shared 2015 · discussion on HN
- 4Breaking changes in Swift 42 people · 1 points · first shared 2017 · discussion on HN
- 5Sentiment Analysis using Apache Hive1 people · 33 points · first shared 2012 · 1 comments on HN
- 6Profiling zsh shell scripts1 people · 22 points · first shared 2016 · discussion on HN
- 7Scala language: (host of) recent developments1 people · 13 points · first shared 2011 · 2 comments on HN
- 8Parsing Text with Scala1 people · 7 points · first shared 2009 · 1 comments on HN
- 9Testing UI Changes in Large Web Applications1 people · 6 points · first shared 2015 · discussion on HN
- 10Security Is Maturing in the Docker Ecosystem1 people · 4 points · first shared 2015 · 1 comments on HN
- 114000+ JavaScript unit tests – from 3 minutes to real time execution1 people · 3 points · first shared 2015 · discussion on HN
- 12Scala actors for the enterprise: Akka framework1 people · 3 points · first shared 2009 · 1 comments on HN
- 13GCC Compiler Optimizations: Dissection of a Benchmark1 people · 3 points · first shared 2015 · discussion on HN
- 14Eight Characteristics of Successful Software Projects – Xebia Blog1 people · 2 points · first shared 2017 · discussion on HN
- 15PhantomJS Data Mining and BASH Data Analysis1 people · 2 points · first shared 2014 · discussion on HN
What HN people wrote when they linked it
anderspitman · 2015-12-24
Love Alpine. The biggest use case I've found for small images so far is for testing a microservices system on Travis or a similar CI. You package each of your services in a container, then use docker-compose1[1] to start everything up. The faster it can pull down the images, the faster your CI build runs, so size can be important here.
One interesting thing about Alpine is that it uses MUSL[2] for its libc. If you want the bare minimum image size, you can use a scratch or busybox image and statically compile your binaries[3].
[1] https://docs.docker.com/compose/
[2] http://www.musl-libc.org/
[3] http://blog.xebia.com/create-the-smallest-possible-docker-container/
hacker_9 · 2017-06-21
Questionable. I would describe Swift as 'move fast' too, judging by the fact there is breaking changes [1] every release.
[1] http://blog.xebia.com/breaking-changes-swift-4/
usgroup · 2016-10-25
Do you mean hackery of this sort:
http://blog.xebia.com/persistence-with-docker-containers-team-1-gluste…
Or do you know of clean, container only (no plugins or special external tools) solution ?
alwillis · 2015-10-27
HTTP2 also supports server push—the web server sends resources that the browser is going to need without waiting for them to be requested: http://blog.xebia.com/2015/08/23/http2-server-push/
ngrilly · 2015-10-09
Interesting, but I’m not convinced.
Size: Each unikernel image contains a kernel specially compiled for the application. A container image properly optimized contains just the application (the kernel is shared by all containers). It’s possible to create Docker containers under 10 MB: see http://blog.xebia.com/2014/07/04/create-the-smallest-possible-docker-c… and http://blog.xebia.com/2015/06/30/how-to-create-the-smallest-possible-d…
Security: Reusing a well known and largely deployed Linux kernel (without all the surrounding provided by the “larger” OS) sounds at least as secure as compiling its own specialized unikernel.
Compatibility: The compatibility story sounds better for containers because your app will work by default without doing anything.
lsllc · 2015-04-26
bookwormAT · 2014-03-13
If you use ViewHolder, consider using custom views instead:
http://blog.xebia.com/2013/07/22/viewholder-considered-harmful/
I refactored all my code after reading this, and now I consider the ViewHolder an antipattern.
It is incredible how much cleaner and readable my codebase is with custom views. And the performance is the same.
chime · 2010-04-22
Yesterday someone mentioned the Sling Blade Runner problem from their archives and I can't stop thinking about it.
* http://www.itasoftware.com/careers/puzzle_archive.html?catid=39#Sling%…
* http://stuffthathappens.com/blog/2007/10/03/sling-blade-runner/
I'm in the middle of writing a web-based anagram server and there's some similarities in both these problems. You have a dictionary that you iterate through recursively to find a solution. For anagram, the solution is usually found with 3-5 recursions (100 word list, 3 recursions: 100^3 calculations - not a big deal for desktop software, too slow for web-app). For Sling Blade Runner, your goal is to keep increasing the depth of the recursion as much as possible so it's actually impossible to go through 100^200 calculations.
Does anyone have any idea if these problems could be better tackled by converting them to map-reduce problems? I'd like to play with Amazon's mapreduce service.
Edit: Neat. I came across: http://blog.xebia.com/2009/07/02/thinking-mapreduce-with-hadoop/