Dienstag, Juni 20, 2017

Programmer Refreshment

https://www.reddit.com/r/dailyprogrammer/ Regular programming challenges

http://ideone.com/ Online compiler for >60 programming languages

(unrelated: https://speckyboy.com/free-responsive-html5-web-templates/)

Mittwoch, Mai 31, 2017

Freitag, Mai 26, 2017

Large Repos (vs. Git)

https://blogs.msdn.microsoft.com/bharry/2017/05/24/the-largest-git-repo-on-the-planet/

We looked very hard at decomposing it and we found that our workflow just was not amenable to that. You might checkout the discussion on Hacker News and elsewhere and find that other large engineering companies like Google and Facebook reached similar conclusion about their core platforms and have adopted solutions with the same general aim as ours.

https://code.facebook.com/posts/218678814984400/scaling-mercurial-at-facebook/

Our code base has grown organically and its internal dependencies are very complex. We could have spent a lot of time making it more modular in a way that would be friendly to a source control tool, but there are a number of benefits to using a single repository. Even at our current scale, we often make large changes throughout our code base, and having a single repository is useful for continuous modernization. Splitting it up would make large, atomic refactorings more difficult. On top of that, the idea that the scaling constraints of our source control system should dictate our code structure just doesn't sit well with us.

https://cacm.acm.org/magazines/2016/7/204032-why-google-stores-billions-of-lines-of-code-in-a-single-repository/fulltext

Early Google employees decided to work with a shared codebase managed through a centralized source control system. This approach has served Google well for more than 16 years, and today the vast majority of Google's software assets continues to be stored in a single, shared repository.

https://www.wired.com/2015/09/google-2-billion-lines-codeand-one-place/

https://svnvsgit.com/#git-scalability-for-larger-project-myth

“While Git is used for such renowned open source projects as Linux Kernel, it does not scale well for truly large projects.”
“While Git is successfully used for such crowded open source projects with thousands of involved developers as Linux Kernel, it may not scale well for other large teams with different workflows.”

Dienstag, Mai 09, 2017

Fuzzing Fossil Gogs

https://github.com/google/oss-fuzz Fuzzing service (for open source software)

https://www.fossil-scm.org DVCS for SQlite with bug tracking, wiki and technotes

https://gogs.io/ A painless self-hosted Git service

Dienstag, April 25, 2017

From ETL to Apache Spark

https://www.youtube.com/watch?v=vZhSbs1xLx4

ETL – Extract Transform Load

Started zweimal? Stellt sich raus: Maus etwas kaputt

https://askubuntu.com/questions/321816/mouse-sometimes-doubleclicks-when-i-click-once

ähnlichen Fall gerade gehabt – spurious mouse clicks in MouseDown

(Erkennung durch Heuristik im MouseDown+MouseUp war möglich und half erstmal)

Mittwoch, März 29, 2017

Microservices

https://github.com/mfornos/awesome-microservices A curated list of Microservice Architecture related principles and technologies 

https://azure.microsoft.com/en-us/services/service-fabric/ Service Fabric

https://www.martinfowler.com/microservices/

Was ist eigentlich mit Testen? Und API-Stabilität bzgl. Erweiterungen und neuen Versionen?

https://martinfowler.com/articles/consumerDrivenContracts.html (via)

Contracts enable service independence; paradoxically, they can also couple service providers and consumers in undesirable ways. […] In short, the enterprise becomes burdened with services.

Neue 1-Pfund-Münze in UK

https://www.thenewpoundcoin.com/

Dienstag, Februar 21, 2017

Montag, Februar 20, 2017

Continous Integration, really?

https://martinfowler.com/bliki/ContinuousIntegrationCertification.html

  • everyone on the team commits and pushes to a shared mainline at least daily
  • commit causes an automated build and test
  • when the build fails, it’s usually back to green within ten minutes
  • using feature branches is Daemonic Continuous Integration

It’s a simple set of questions, but it gets to the core of what Continuous Integration is about. The whole idea is that nobody is working on a code base that deviates significantly from anyone else’s. Continuous Integration means the team knows what the current state of the code truly is, we avoid big risky merges, and people can refactor as much as they need to.