azurelogic

Another vote in favor of disc brakes. There's a greater sense of braking power modulation with disc brakes. If your rims aren't true, you're going to have a bad time with rim brakes. Also, I remember the huge difference in cold weather performance, which mattered a lot to me during the cold Midwest winters during college.

The same thing has happened with cars and performance. Stuff gets heavier, more expensive, and more complicated, and yet we manage to squeeze greater performance and efficiency out of less displacement. And then there's the eye watering power that comes from marrying this kind of tech to a big V8.

I found myself in a similar position a couple of years back. One of the big things that changed for me is that I had to widen my field of view on a project. I had already worked the "full stack" through previous jobs, but now I was responsible for designing how everything connected: APIs, CDNs, servers (or "less"), storage options, security, CI/CD, etc. It's not unlike how we grew from single lines of code to functions to modules to applications. Now, you move to assembling all of the mechanisms into complex systems. Based on your training, I imagine you already know a good amount about the various tools at your disposal, and it is time to apply all of that together.

Your days of learning new things is not over. You don't need to know the minutiae of everything, but you need to know what can and will work together, what may cause pain in integrating, and where your risks are. Oh, and you'll have less time to tinker your way through the new things.

There are things that you may not be used to doing though. You'll spend more time in meetings trying to figure out what you're actually supposed to be building. You'll spend time investigating new tools to use (replace libraries and packages with services in your mind). You'll probably be expected to do even more project planning and estimating.

And one of the most difficult for some people: you'll have to delegate. I still struggle with this one sometimes. You cannot possibly build it all, and now the people you have to rely on to build it will probably lack your experience, and on top of that, it's up to you to make sure that the requirements are crystal clear to them. And that's not their fault. We were all junior devs at one point. Crawl, walk, run. On the flip side, remember that some people WILL have experience in things you don't. Identify those strengths and leverage them!

Oh, and there's a decent chance you'll need to manage how much all of this crap costs... Brilliant solutions aren't so brilliant when they cost more to run than they generate in revenue.

As someone who has been working almost daily with Lambda and other AWS serverless services for close to 2 years, it astounds me to see so much FUD and misinformation among one of the smartest technical communities that I know.

Serverless is about making as much computing power as you demand available on demand with a "pay only what you use" price model without demanding that you maintain the underlying systems. In addition, embracing this model tends to allow you to break out of the request driven model of needing to call APIs for everything. Instead, you enable a whole host of new event driven interactions between application components.

Even this article misses one of the more interesting advantages: scalability under varying load. AWS Lambda may cost more than an equivalent EC2 instance if run constantly, but it scales up and down almost instantly without adding cost. You just pay for the compute time. So, burst traffic is no sweat (up to your account limits or function configured limits). If your application has highly irregular load, Lambda can keep it more responsive while saving you money too.

And it is nothing like paying for shared hosting or other single unit, where you still have no horizontal scalability.

Exactly. With this definition, the phrase "compare and contrast" makes much more sense. The point here was to leap frog the fact that GitHub and GitLab have very comparable feature sets, and instead highlight the things that GitLab has that GitHub is totally missing.

You're right on the first point. They aren't comparable. GitLab is a community driven, open core product that is far more powerful than GitHub. GitLab has an extremely robust CI system built in. In addition, you can even use them to create private Docker registries, which I find useful for creating my own private CI images. Plus, they have a better security model (5 tiers), wildcards for branch protection, and tag protection. I'm sure there's other places that they differ, but before you disparage a company, please be informed about who they are and how great their product actually is.

If you want to self-host FaaS, there's OpenWhisk. The problem that I have seen with the whole concept of self-hosted FaaS though is that you lose some of the key benefits of "serverless": no maintenance of underlying systems and pay for exactly what you use. Self-hosted means you have to maintain the underlying systems and you have to pay to keep those servers running 24/7 with sufficient scale to support your usage model. It may make deployment easier once you adapt to it, but it's not really giving you the full benefit.

This page was immediately taken over by the ad redirects for free iPhones and crap. Can we get this replaced with a not shady source?

I've been wishing for something like this or a standalone unit for CarPlay. It would be amazing if I could just mount something in the CD slot in my car and plug in to the aux jack. I'm sure Apple would have a cow at the idea though.

All computers have the potential for slowdown as they age because 2 things naturally happen: cooling systems clog with dust and thermal paste degrades. Both of these eventually reduce the efficiency of the cooling system, resulting in higher CPU temps. Unchecked, this can result in CPU throttling by the hardware itself.

Maybe the poster is talking about total sunk cost of phone and all of the batteries

This has nothing to do with a monopoly, so antitrust law is totally not applicable here. You might be thinking "class action lawsuit", which someone might attempt. However, if Apple can show that this is actually a mechanism to provide maximum screen time for the life of the battery (as opposed to malicious planned obsolescence), the suit would likely fail.

It is but you see less screen time instead of degraded performance. The suggestion here is that Apple is throttling the hardware via software in order to prevent reduced screen time.

Also, after 3-4 years with a laptop, you typically start to see decreased performance because of clogging of fans, degradation in the thermal paste, etc. This causes the CPU to run hotter and throttle sooner to stay inside of its thermal envelope.

I don't know enough about the physics, but it could be similar to the difficulty in making glasses-free 3D TVs. Things like the Nintendo 3DS only succeeded because they naturally dictate the viewer's position. I imagine that this kind of thing would be easier to develop if you could control the focal point (i.e.: strapping someone's eyeballs into place).