rosshemsley

GitHub pages:

You can use custom domains with SSL

Here's a full example:

https://github.com/rosshemsley/rosshemsley.co.uk

Whilst I don't totally disagree with many of the points here, I think there's a wider picture to many of these issues.

The author is concerned with installing packages on user machines: which are typically very long-lived installs - maybe a user has the same machine with the same dependencies for years.

However, for many engineers, (such as myself), a binary may not be used past even a few days from when it was first compiled - e.g. as part of a service in a a quickly continuously integrated system.

I might even argue that _most_ software is used in this way.

When software is built this way, many of the points in this article are very helpful to keep builds stable and to make deployment fast - and in fact for the case of security, we usually _don't_ want dependencies to auto-update, as we do not want to automatically deploy new code if it has not been audited.

Maybe there's a future were OSs become more like this, where binaries are more short lived... maybe not. Although I don't think it's strictly fair to label all of these as "Bad" with a capital B :)

Protip:

On OS X you can set it so no icons appear on your Desktop.

For me at least, having that "new laptop" clean slate at all times helps me maintain focus :)

Pytorch is a good option here - ultimately it's just a library for efficiently manipulating tensors and supports cuda GPUs.

"if you need a tool, buy the cheapest one you can find. If it’s inadequate, or breaks, or you use it a lot, then buy the best one you can afford"

I don't know how I feel about this... The unsaid thing here is that you will end up landfilling the broken or inadequate tool and buy twice what you need.

These days, if I'm going to put money into buying material goods, I feel they have to meet at least a minimal "this isn't going to end up in landfill after the first time I use it" bar.

A lot of cheap tools barely meet this level, sadly...

I think a common conflation is seeing "making something future proof" as "making it more generic".

IMO, good future-proof design is about putting in place good components and system boundaries.

Those components and boundaries can be highly specialised and have as few options as possible - it's much easier to make a system boundary more complex than to make it simpler. So start as simple as possible!

Now, with those boundaries, you can easily write tests, and iterate on the different parts of the system. Bad code in one component doesn't "infect" bad code in another part of the system.

Most "balls of mess" systems that I have seen came down to not having clear boundaries between components of the system, rather than being too generic or not generic enough.

A litmus test I'm excited about is writing a less clunky linear algebra / numerical optimisation package.

Gonum is good, but it can feel like a lot of the powerful abstractions in numpy and Eigen are difficult to replicate.

Whilst numpy and Eigen do "turn the magic up to 11" just a bit too much for my liking, I do like the idea of things like this:

    interface Scalar() {
        type float float32 int int32 int64
    }

    type DenseMatrix(type T Scalar) [][]T

    func Identity(type T Scalar)(int size) DenseMatrix(T)

Features I wish C++20 had:

* An opinionated, modern packaging and dependency story (like go modules, Rust crates)

* built-in library support for logging, http, zip, gzip, json, yaml, template rendering, RFC3339 datetime reading/writing

* the dream: compliant compilers must be able to compile down to static binaries, cross compiling built-in.

Features C++20 actually has:

* new fancy spaceship operator that I'll now have to learn and never use...

Could this actually be a profitable business, selling carbon offsets?

Perhaps an easier (and more robust) way to do this is as follows:

1) Take your points in 3D, and add the point at the origin

2) Compute Delaunay in 3D

3) The 2D faces not containing the origin is your triangulation.

To get the Voronoi tessellation:

1) Circulate the faces of each vertex in order (use orientation test if they are not ordered yet)

2) Connect the circumcenters of each 2D face you visit.

Voilà!

The cynic in me expects to click this and find an article about trees.

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

I was seduced by BlueOcean and tried using Jenkins for CI, using Github and AWS ECS builders (which felt like a common enough use-case).

Unfortunately it ended up costing an astonishing amount of engineering time to get working and maintain, with builds frequently stalled or failing.

Since moving to CircleCI 2.0 enterprise (admittedly far from perfect) and Airflow, we have _dramatically_ reduced eng. time spent managing our job scheduling.

The core of our problem was how fragile and complex the Jenkins ecosystem seems to be: any change to the config or settings and it would easily burn a day of engineering, due to random bugs and hard to understand error messages. In the end, no one wanted to touch it!

I think there's a great project hidden somewhere here, but just getting the basic "everyday" stuff done with it can be a real PITA.

Go excels at:

- Anything that talks to a network (webservers, load balancers, caches - due to the fantastic built-in support for everything you eed, and concurrency primitives)

- CLIs (static linking and cross compiling make distributing binary CLIs a piece of cake)

- Gluing stuff together (it talks C, and all your favourite libraries are probably already available (gRPC, protobuf... etc)

- Munging data (expect orders of magnitude speedups over Python)

Go is bad at:

- GUIs

Why consider Go over other things?

- For me, Go is "the language with the least BS" there is. The "let's just get some engineers writing some code and ship it" story is literally miles ahead of Python/C++/Java/X language. It has been painstakingly crafted to minimise friction onboarding, building, testing, upgrading, and deploying.

Anyone have a bullet-pointed summary of the "crux" of what the author dislikes about MVS?

I find MVS to be a very natural and simple solution to versioning - I feel like it's much closer to how people actually manage their dependencies in practice.

After an admittedly low-effort skim of this article, most of the arguments seem to be that the author doesn't think it "feels right". Is there something more concrete hidden in here?

Yep I know it :)

My joke was "Oh, I should return a unique_ptr<>, but then I will be losing out on the make_shared optimization" ;)

I actually thought this would be about yak shaving due to the huge number of ways to achieve everything in modern C++xy.

My internal monologues when writing modern C++ look a lot like this...

So I have to return from this function... it uses a lot of resources, so I don't want to copy it. But then there is RVO... Although is this actually NRVO? What was that rule again? I guess I can rely on move semantics? But only Scott Meyers himself understands those and he promptly exited the C++ community after figuring them out... And anyway, what if I want to change the ownership explicitly? Let's just use a unique_ptr. Oh but actually I mostly want to share it when I have returned, and that means two blocks of memory will be allocated per pointer instead of the optimal "single" allocation with the reference count at the beginning. Although maybe that's only in libc++? oh, and what if there is an error, should it return nullptr in that case?..

Nah, plenty of overlap :) building networked services that deal with lots of data.

Fair point. My feeling has been that the committee is trying to make the language safe (as is now the fashion) by adding increasingly more features, with the intention of deprecating old workflows aggressively.

But the language complexity is now so significant that a new dev would take years to fully understand both "old" C++ and new C++, and how to make them work well together

This could be a joke. Or not.

It is very much in keeping with the current direction of C++, which appears to be:

"Oh no, C++ cannot keep pace with modern systems languages, let's repair it by whatever means possible"

Their heart is in the right place, but perhaps this accelerated process of mutating the language will ultimately be what kills it.

Personally, after having deep expertise in C++(11/14) I jumped ship to Go and will _never_ look back...

Blue Vision Labs | London, United Kingdom | Onsite, Visa, http://www.bluevisionlabs.com/ Stealth startup working on augmented reality, self-driving cars, and robotics. Founded in a Y-Combinator Fellowship and backed by Accel (Facebook, Dropbox) and Horizons Ventures (DeepMind, Siri).

Our team comprises experienced software engineers, accomplished entrepreneurs, and PhDs from top universities. We offer a full range of benefits, a friendly and dynamic atmosphere where everyone learns, grows and contributes to our core product.

We are seeking ambitious people with industry experience to join our team:

  AR / VR Developer   | Mobile (iOS / Android)
  Software engineers  | Backend, Data, Pipeline (+internships)
  Software engineers  | 3D Visualisation / Graphics
  Research engineers  | Computer Vision (+internships)
  Research scientists | Computer Vision

  Flexibility
  Competitive compensation and equity packages
  Central London office
  Free breakfast/coffee/lunch/coffee/gym
  Visa sponsorship

One of my favourite examples:

A friend once sped up some code 90% by changing a

list.size() == 0

to

list.empty()

yes, std::list::size() can be _linear_ in C++98.

http://www.cplusplus.com/reference/list/list/size/

If you don't understand something doesn't mean that this is just for fancy optimizations.

You should definitely understand it, but if you find yourself wanting to use it, you should start by considering alternatives first. It's a sharp (and often unsafe) tool that should be avoided in most cases.

For your example, unique_ptr is the correct (and safe) solution and will do the same thing.

you don't need expensive atomics (shared_ptr)

Note that shared_ptr provides no "atomicity". It is in reality exceptionally cheap.

One useful rule of thumb that works 99% of the time in C++11 is:

Never use "std::move"

It's really just there to allow fancy optimisations and you don't need it in most cases. You should rely on the sane defaults instead:

- Putting variables on the stack to manage object ownership/lifetime is a good default.

- Use std::unique_ptr or std::shared_ptr() for heap ownership (single ownership vs. shared)

- For a non-owning (mutable) reference, use const & (&) or const * (*) when the value may not exist.

- Always prefer passing by value (return types and parameters)

- If a parameter type is heavy, take a (const) reference.

- If the return type is heavy, the compiler's RVO will do its job.

No need to be more fancy than this

Yes, but the O(N) is generally only for pathological inputs.

Geo data is generally nicely distributed. R-tree (or similar) is the correct solution here.

Ridiculous article.

'Highest QPS?'

This is a trivial geometric problem, any sane implementation should be several orders of magnitude faster than doing network IO. /rant

Bringing namespaces into scope is perfectly idiomatic C++, just don't do it in your headers.

I was checking out your site, but I am getting a DNS error for http://l.en.opensignal.com (both on my local machine and server.)