spricket

11 ms·

61.
by spricket 8y ago
They use cathodic protection which makes the underwater hull basically immune to corrosion. But this doesn't stop water that gets on top or inside. Ships rust like hell. I've known some guys in the Navy and they said it was common
62.
by spricket 8y ago
If your services were all setup the same, what was the big advantage to have them separate? Wouldn't you get the same scalability from running 10x of the monolith in parallel with a lot less work?
63.
by spricket 8y ago
We actually tried this as well. It never made it out of testing. We ended up with copies of data in many places, which was annoying. We duplicated a lot of work for consuming the same events across multiple services and making sure they upd
64.
by spricket 8y ago
Heh, definitely some truth to this. What saved us before, was our forest of code could depend on the database to maintain some sanity. And we leaned on it heavily. Hold a transaction open while 10,000 lines of code and a few N+1 queries do
65.
by spricket 8y ago
I agree that the type system is very complex. I've spent a lot of time wrapping my head around it and still get confused sometimes. Unfortunately Typescript's type system is largely driven by the need to represent anything you can
66.
by spricket 8y ago
I don't think so. This kind of thing comes up constantly in RDBMS. New requirement means we need to join thneeds and widgets data together. In a regular database, even NoSql, this isn't a hard problem. When the services have their
67.
by spricket 8y ago
It's not that easy in my experience. They use different databases. Different versions of frameworks. Some written in different languages. We tried to have a "one size fits all" CI pipeline but that fragmented over time. The o
68.
by spricket 8y ago
I agree, because type inference in some (Typescript) is good enough that there's almost no overhead. Back when it took twice as many lines with types it made sense. But the overhead in typescript is maybe 10%, worth it anymore? I don&#
69.
by spricket 8y ago
Microservices. They seemed really cool until I worked on a few large projects using them. Disaster so epic I watched most of engineering Management walk the plank. TLDR: The tooling available is not good enough. The biggest cause lies in i
70.
by spricket 8y ago
My guess is that this uses public key cryptography. Generating a signature is rather expensive. We found this out the hard way a few years ago, when we tried to verify OAuth tokens using RSA rather than HMAC. The server was hammered at mayb
71.
by spricket 8y ago
While I'm a big fan of Rust, excluding Java because "JVM" is kinda laughable. It's not hard to run at all. You package everything into a jar then run a single command. As easy to get working as a JS backend. If their com
72.
by spricket 8y ago
I agree. C# is wonderfully designed, only reason I haven't switched is the huge number of wonderful libraries available in java. Also sad that C# went asynchronous. I mean, it works great, and it's better than what Java has now, b
73.
by spricket 8y ago
It depends. Number one, find out if the codebase is bad or just big. This will take a few months, so I try to keep my mouth shut for a while. If it's really that bad, build a world in a teacup. Try to make one small new area of code th
74.
by spricket 8y ago
Might as well add my own? Constantly recycled job openings - to spot this you need to be searching for a few months. But if you notice that the same posting is ALWAYS up for senior positions, and it's not a huge company, your resume ha
75.
by spricket 8y ago
This feels language specific. Java has excellent thread support for example, it's quite hard to build an application that deadlocks. Thread-per-request is how everything used to be done. Most languages switched to pools because of huge
76.
by spricket 8y ago
It really comes down to having code I can copy-paste. Google's documentation tends to be minimalist, like a research paper. One small example for everything, just enough to cover every feature. AWS is closer to "copy paste this bi
77.
by spricket 8y ago
It's an example of how they treat "old" code, services or otherwise. Fixup your code to use new version or you can't build. Replace "build" with "deploy" and you have the policy of GCP. Now it's
78.
by spricket 8y ago
Thanks, I used to do consulting so I've seen this firsthand. Many of our non-technical clients demanded Azure even when it wasn't ideal (this was years ago, before they cloned most of AWS). Why? Microsoft is known for long term su
79.
by spricket 8y ago
The reason for IBM's failure is pretty obvious. Their old school bare-metal servers at Softlayer are a good value, but the need for bare metal is decreasing with IO improvements like SR-IOV and real hardware level virtualization (ex HV
80.
by spricket 8y ago
That really is a problem for anything bandwidth constrained, even today. They're even trying to replace RSA at ~2kb per key. Part of it is also the human factor. Crypto is way easier if your keys are short enough to write down. You don
81.
by spricket 8y ago
I hope Rust comes of age in a few years. Java, Go, and C# are above 50% "native" speed in every benchmark I've run across, but the mantra continues to be "why would I pick something slower?". Rust is the answer ever
82.
by spricket 8y ago
I guess another real advantage of SPA is that you get an API for free. Last place I worked, the product people had a genius idea to "build a public API". They decided to give us half a year to do it. We had a SPA using OAuth. I sp
83.
by spricket 8y ago
Exactly, this explains why my Java code is 108% bug free
84.
by spricket 8y ago
I've found the most annoying aspect of using a SPA is having to consume your own API's. Using Swagger or gRPC on both ends helps immensely. These, combined with Angular CLI or Create React App, allow me to be just as productive as
85.
by spricket 8y ago
No definitely not. Reply with a link to any benchmark from the last couple years and I'll believe you
86.
by spricket 8y ago
Agree 100% Koa from the original devs of Express is amazing. Rails is worthless for modern webapps, there's just much better options
87.
by spricket 8y ago
This ain't a good defense for Ruby server-side. They're working on speed, okay. is that not where the bottleneck is? Perl 6 is coming too I guess Because on production servers we have 10 Ruby front ends for a single Postgres datab
88.
by spricket 8y ago
Ruby is going the way of Perl, same as the Dodo. I wouldn't recommend anyone learn Ruby over Typescript, JS, Python, C#, or Java. There's too much magic and Ruby is seriously sllllooowww. Slower than PHP, Perl, and Python. The mai
89.
by spricket 8y ago
Running Matrix + Riot.im for my "family chat" server since Hangouts is going away. Bit hokey to setup but highly recommended. Fast enough for us and it's nice to be able to save all the pictures your family sends in full qual
90.
by spricket 8y ago
I agree with the author completely. I worked on a fairly large system using event sourcing, it was a never-ending nightmare. Maybe with better tooling someday it will be usable, but not now. Events are pretty much a database commit log. Thi

More ›