exterm

Cybernetics

https://simplexity.quest

I've encountered a lot of confusion on this topic and hope people find this article helpful.

Also if you find any mistakes I'd be happy to correct them!

Shopify has been a fully remote company for a few months now. https://financialpost.com/technology/shopify-is-joining-twit...

We're not using zoom, but google meet - but yes, these happen completely online now.

I find that people that are doing interesting stuff often _want_ to talk about it. However, a big part of Shopify culture is "do things, tell people" - it is definitely encouraged to spend time spreading context.

It's not directly part of any rewards framework, but one metric that goes into promotions is the area of impact. By giving a talk to the guild, you can have impact on a group that's larger than your team, potentially the whole organization. It counts.

But another reward is the positive feedback, interesting discussions and new connections that you make through this.

When I left, we were up to a few dozen components, and the number was climbing rapidly.

I should have included this in the blog post: The number of components _needs_ to be kept small. Shopify's main monolith is 2.8 million lines of code in 37 components, and I'd actually like to get that number _down_.

I like to compare this to the main navigation that we present to our merchants. It's useful if it has 8 entries. It's not useful if it has 400.

In a way, components are the main navigation to our code base. A developer should be able to look at what's in our "components" folder and get a general impression of what the system's capabilities are.

extension points to the way engines are implemented that could better enforce boundaries

Can you expand on that? I'm not sure I follow.

you should read the first post in the series if you want to read about microservices. https://engineering.shopify.com/blogs/engineering/deconstruc...

It's all tradeoffs. You get a stronger boundary, but you also get a distributed system.

Also, the first try of drawing boundaries will always be varying degrees of wrong. If you have very strong boundaries at this stage, iterating on them, moving responsibilities around, can be harder.

Also, with the right tooling it's definitely possible to harden monolith internal boundaries to a comparable level.

I can see though how many smaller companies would not be in a position to build that tooling.

Anyway... there is no either / or here, as I've explained in another comment. What if you have components within a monolith, but each component has its own database, for example? What if test suites are completely isolated, so that tests for component A can not access code in component B?

You can get pretty strong boundaries with a few comparably simple tricks.

you don't work with Ruby eh? :D

Hey Leafboi - I recommend reading the first post in the series for some background https://engineering.shopify.com/blogs/engineering/deconstruc...

We don't use "hardware" or "VMs" to facilitate modularity.

oops - sorry. Opened for now.

components are

- same database - same runtime - same deployment - same repository

That said, I don't think this is an either/or. It's a spectrum. you can have components within the same runtime and repository that have separate databases, or components that are using the same database but live in separate repos, etc.

From one monolithic app towards fully separated microservices is a spectrum, and I think developers should be enabled to move freely around that spectrum.

As the author, I would know :)

Thank you for the praise.

Ours kind of organically grew over time, but as I've been keeping it alive for the last few years I have a pretty good idea of how I would start it fresh.

You probably have some people in the company who either know much more about architecture than others, or are working on projects that are more interesting in terms of architecture. Find one of them, convince them to give a 15 min talk.

Announce the talk widely within the company, tell people to come to the new "architecture guild" slack channel you created to get the details / invites.

Schedule an hour to give plenty of time for discussions after the talk.

Repeat biweekly.

It's certainly related. In very general terms, I would say splitting a Rails app into multiple engines is the same pattern as umbrella applications.

However, there are more interesting specifics here about things like all engines sharing a database, but having exclusive ownership of tables, as well as splitting HTTP routing over multiple engines etc.

The answer to that question could probably fill another blog post :D

Long story short, Rails and dependency inversion equals lots of friction. The whole framework is built on the assumption that it's OK to access everything from everywhere, and over the years we've built lots of tooling on top of those assumptions.

E.g. we heavily use https://github.com/Shopify/identity_cache with active record associations that cross component boundaries.

We also have a GraphQL implementation that is pretty closely coupled to the active record layer and _really_ wants to reach into all the components directly.

All of those problems can be overcome, but this is definitely an area where we have to working against "established" Rails culture, and our own assumptions from the past.

There are quite a few people talking about this kind of stuff on https://rubymod.slack.com. I can send invites, just DM me on twitter https://twitter.com/_exterm

Very interesting discussion, although there already are solutions to some of these problems in other type systems.

Erlang also has optional type annotations via the dialyzer tool and all types are by default non-nullable.

Generally I think that the dart language implementors should try harder not to copy language design fails from Java / C++, like null-pointers or half-baked enumeration types.

Because they officially support only ubuntu and mint. The provide a tarball for other distros but don't officially support them.

I agree, there will be lots of low hanging fruits. But I guess GOG is playtesting every single one of them so it could take a while. The linux testing team is probably smaller than the windows and mac teams.

Just speculation ;-)

Can't wait for them to give more of their extensive back catalog the linux treatment.

With this and steam linux edition, the future looks bright for linux gamers.

Playing colonization on linux this evening :-)

No, the Opera user agent contains an additional OPR/XX where XX is the Opera version.

Nice idea!

ages ago?

Opera 12 will indeed be updated with security patches for some time. "You can expect that we will keep Opera 12.x up to date and secure." http://my.opera.com/desktopteam/blog/2013/07/02/opera-15

regarding "tab-screenshots": Opera calls them visual Tabs. The linked article says "Right now, we are focusing on synchronization (aka Opera Link), enhanced tab management (visual tabs and so on) and support for themes – and these are just a few of the features you can expect to find soon in our next releases!"

Download manager is still included. Other features will follow, although email has been split into a separate product, Opera Mail (http://www.opera.com/computer/mail).

The size increase is due to a complete rewrite based on chromium.

More in-depth release message on their developer blog: http://my.opera.com/ODIN/blog/2013/07/02/introducing-opera-1...

All I have heard is "Linux will follow", no mention of FreeBSD so far.

It is based on chromium including blink, which is a webkit fork, so yes, it is.

Linux version will follow, maybe not for opera 15 though but for the next release.

edit: Taken from official statements on the opera desktop blog, http://my.opera.com/desktopteam/blog/