russianator

Not everything needs abstraction.

FP (Functional Programming) has it's place. Sometimes a pure function is a beautiful thing to have.

It's also ok to mix OOP and FP.

Main advantage is the full sized keyboard.

If you do a lot of coding, it's just a better ride than "compressed" keyboards.

13" is a nice form factor, but I find the 14" X1 just has enough space to give a nicer typing experience.

Just my opinion, you should see if you can try one out, and see what you think.

I've had one of these and it runs Ubuntu really well.

Personally I actually prefer the IBM X1 Carbons, they have the nicest keyboard I've ever seen and a good keyboard is IMHO a must for a coder hacking keyboard.

In my opinion, you lose out where transferrable skills are concerned.

You become a platform or product expert, which can effect your career in some ways.

I've seen this in situations where products from companies such as Salesforce are concerned.

I didn't want to become a Salesforce platform expert, I wanted to be able to pick the right tool for the job, regardless, and saw heavy investment into a single platform as a disadvantage both for the organisation as well as myself and our engineers.

This is purely my opinion from the perspective of a developer/engineer who has seen my solutions removed with little understanding for the engineering and people consequences in an organisation.

The issue with nocode SaaS products is the misconception given to non technical people about what is replaceable.

Often a good business decision does not equal a good engineering decision and the management structures in place don't allow for this type of discussion to take place. This is where developers and engineers are beat out by "it's better for the business" as a decision.

Often executive managers who have moved away from technical work and are very far removed from deep (as opposed to wide) engineering knowledge, this can promote animosity between management and engineering.

Again this is purely a view/opinion from my own experience.

The organisation needs to understand: 1) What are the needs we are fulfilling 2) Are we building up engineering where we need it

When question 2 is disregarded when engineering built solutions are discarded this leads to the degredation of engineering "credit" in an organisation.

Only if you have 1,000 apps being messed with by a monkey

I would argue that there are boundaries to this sort of behaviour though.

There should be open discussion about these things.

Passive aggressive behaviour, which sounds very unprofessional.

If his manager is enabling or ignoring this behaviour, I would wager there is some toxic culture in action here.

Having said that, you should have a manager that you can give and get feedack to and from. Be open to criticism but also note any behaviour you feel is unfair or unbalanced.

If it looks like noone cares to openly discuss this behaviour I would start looking for a new job.

This is akin to Salesforce, Oracle and other certifications of their ilk.

https://vercel.com/docs/serverless-functions/introduction

I've been using https://vercel.com/ for a while now.

It has built in gitops and a very simple deployment model. Works really well with custom domains and cost-wise it is great as it doesn't break the bank for my side projects.

It includes CDN capabilities with CloudFront-like honouring of cache headers, etc as well, so I haven't found anything lacking even though it isn't as feature packed as something like AWS Lambda.

For things like queues, databases and memory stores I used other managed services.

Another vote for distowatch.

I go there from time to time when I get bored of Ubuntu :)

Rule number one, be honest.

Rule number two, don't wait to have difficult conversations, do it as soon as something arises.

Rule three, delegate organisation tasks to your team.

I still struggle with time management personally, I'd be interested in others opinions on this as well.

You will have to balance delivery over care, or going fast over doing top quality work.

Solicit feedback from your team about how you can help them.

Also, work hard to prevent burnout.

The best way to gain trust is to show you are working for your team and not for your manager.

And don't ever listen when someone suggests one on one meetings with your team members could be a waste of time.

https://zeit.co/

Supports Node.js, static and docker containers.

Very easy to use with custom domains.

My extreme view is to just block.

But a more measured approach is to ensure it is flagged as a paywalled item.

After taking lessons I just played along to tapes of my favourite artists.

I would also recommend learning tablature.

Enablement means having choice. Choice means using open standards and not closed proprietary platforms.

Often I see developers feeling trapped when they are unable to choose the best tools for the job.

Allow developers to be creative, period.

The best line of code is the line of code you don't write.

The best gun is the gun you don't have.

Less guns less gun violence, it's not rocket science!

Another vote for the XPS, I have a 9360 with bare metal Ubuntu.

Works flawlessly and the screen is very nice.

Control what you can, look elsewhere for another job, then quit.

If your company is unwilling to change, change your company, find another job.

And priority one is your family!

There's an actual API documentation standard called Blueprint API with some tools for this. https://apiblueprint.org

Was that a parody of the parody?

These days you shouldn't use a monolithic architecture IMHO, you should consider creating services or microservices with Node.js to provide API's to a "headless" frontend.

Depending on your "workloads" you can start simple with just API's to support your frontends, and then expand your architecture to include services for other services. You would need to consider whether you need caches (redis) or databases (postgresql, mongodb, etc). All these can be containerised as well.

There are also frameworks such as next.js and nuxt.js which can ease the server side rendering side of things, depending on your choice of frontend view library (React/Vue).

In terms of orchestration and deployment, consider building your services with a Dockerfile.

I've had some success for personal projects using something like Rancher (1.x) for easier orchestration and scaling of containers. But at some stage you might want to learn how to use Kubernetes, since it seems to be the in thing now for container orchestration, scheduling, etc. Rancher allowed me to manage hosts and clusters on multiple cloud providers once I had the Rancher manager node setup.

So it can vary from case to case, depending on what your app actually does, you could still use koa+sequelize + passport for your API's. The above are just my own suggestions.

If you choose to go down the serverless road I would recommend checking out the Serverless framework, which can help you with deving as well as deploying to your cloud provider of choice.

Good luck!

Micro Node.js microservice library: https://www.npmjs.com/package/micro

React SSR framework: https://nextjs.org/

Vue SSR framework: https://nuxtjs.org/

Rancher for Docker things: https://rancher.com/docs/rancher/v1.6/en/

Serverless: https://serverless.com/

While I work with Node.js a lot, and love it, I have to say this is not a very even handed article.

Feels like the team the writer was working on had some cultural issues around particular languages.

I have personally worked in companies where I've seen Java devs switch between Java and .Net languages without so much as a single whinge.

Overall a very biased piece of work IMHO.

I've used these guys in the past https://zeit.co/pricing

They have a decent free plan and their Pro plan is pretty good value.

Over 40 and still active, whatever that means :D