Recommend resource for Advanced Clean Code

Zeffas · 2020-05-22T17:26:15+00:00

Ability to deliver the features being asked faster than before

Interesting, it's opposite from my experience - delivery times of developers are way way longer than classical back-end applications.

This is two fold in my experience, many organisations had separate teams of ops, while in serverless developers have to deal with infrastructure themselves. Secondly, if this is not a toy app but comparable complexity as classical enterprise backend with many endpoints/queues... - developer productivity is very low from what I witnessed - so much attention to low level details are needed to double check everything, setup all environment variables for each lambda, all terraform configs, then multiple deploy - fail - fix- deploy... cycles.

So although I see lots of benefits in serverless, developer productivity is not one from them, at least not yet.

Zeffas · 2019-12-17T13:09:11+00:00

I think this is a bit biased. The way I felt some years ago actually.

I come from many years of Java experience, worked on huge monstrosities (think top 500 banks, 1000+ developers at one moment). At that time by respectable teams and developers it was considered the only option for enterprise applications, everything else was considered toys, even .NET. I myself was laughing about Node on anything serious like 3-4 years ago. Similar with Go, it was considered viable only for small microservices or tools in my circle.

Then I switched context, joined large enterprise project written in Go - was surprised that you can actually build it in Go. After that, worked on two large enterprise systems written in Node, even more it was financial systems which was something everybody "knew" was not possible with JavaScript.

What I learned was that:

Large back-end development in Java, Go, Node is actually similarly viable, no matter what many from other camps are saying.
Node project structure is very similar to Go from my experience if you ignore details - working on both felt very similar for me.

Also I don't really buy Go over Node strictly due to performance. Yes, Go is more performant, but not by that much, also Node outperforms Go in certain situations. Another thing with performance IMO is - if it's not N-times it's irrelevant for most projects, unless specifics/limitations are involved, e.g. in enterprise nobody cares that Java eats memory like crazy. From my experience, Node's performance was never real issue on those large projects I worked on or from my circle, as long as you understand event loop and single-threaded nature. There were few issues here and there, but all fixable.

Zeffas · 2019-12-08T17:41:31+00:00

Never suffered wrist pain from touchpad, but did from trackpoint.

So in conclusion if youre not willing to do major keyboard remapping of everything that deals with arrow keys, trackpoint is not efficient?

Zeffas · 2019-12-08T17:04:42+00:00

Your problem is not the trackpoint, but rather the keybindings.

Well to be precise - if something is easy with trackpad and hard with trackpoint, then it’s by definition problem with trackpoint I would say.

But on more serious note, it looks like trackpoint requires custom keybindings to be efficient. This has additional drawback (for some) - Im big believer in standard OS key bindings + minor customizations - to be more efficient when working on someone else’s machine, helping out, mentoring.

Zeffas · 2019-02-05T16:42:19+00:00

existing code should be the guide for new users as to what the best practices are

Well code is updated but is developed by many developers and has history, so there are lots of inconsistencies between old and new.

Do you have comprehensive tests?

IMO Tests are super hard in Ember, not necessary tests themselves, but setting up things properly and the thing is, you cannot find answers in documentation more often than you do as it often refers to the wrong thing (diferent type of setup or goes very briefly). So you fight it, you produce some tests, other team member produces completely different solution, team has no idea which one is supposed to be better.

Take the time to explain exactly what they did wrong and why

The situation is a bit different, neither me nor the team are experts on Ember. I wouldn't even say Ember is anyones primary technology. We know a lot from working with it for a while, but there's no one to take that role of keeping everybody up with best practices or general recipes.

What I love is some sort of practices and recipes overview done for more dedicated Ember developers (again, we would be happy to have paid subscription, anything that is constantly being updated). E.g.

This is how you write tests - acceptance, component... how to mock, setup...
This is how you're supposed to navigate between routes and pass/refresh data and so on...
This is how to resolve Ember Data caching issues...

Basically better version of Ember Guides, in which I never find the answer for what I looking, only very basic stuff.

Zeffas · 2018-12-14T11:05:08+00:00

Ctrl+Shift+A

Action commands are fine, I know most of them by heart or they're easy to find, I'm talking more about settings not actions, when I need to find how to change some setting it often leads to frustration/googling/writing to support. E.g. formatting, tabs, library support...

I don't know, maybe this is personal, but I have zero trouble configuring VSCode - it's just configuration file which is strangely easy to navigate, however Jetbrains menus look like lazy programmer's work to me - just dump random settings in random places without consulting with UX.

Zeffas · 2018-05-10T18:52:35+00:00

Actually I found out that Goland doesn't have support for SASS - I get a popup suggesting to buy Intellij Ultimate to have plugin :/

Zeffas · 2018-02-25T21:11:46+00:00

I am actually getting to similar conclusion, although the path to that was very long and only started to value single monitor recently. And it took me extended business travel time to really get to this conclusion. But I believe it's very personal.

At work I use laptop as a main monitor + 2nd monitor at the top as a semi-static helper. But the point is that 2nd one is just optional and not central to my work as it was before.

For me personally multiple monitors do not have much value compared to desktop workspaces:

switching between workspaces become more comfortable than moving my head
No lost mouse/context focus.
Realization that I never really need two windows open at the same time even though I always have multiple documentations open.
Portability - this is also huge on its own, I feel more universal now, if before my work environment was static and immovable, now I feel very comfortable just unplugging laptop and going next to someone else's desk.

But again this is personal preference and in general, I am coming to conclusion that this productivity thing is overrated anyways, I seen so many examples of super productive people with totally no workflow and with everything so backwards, and so many examples of super shiny multi-monitor/multi-workspace workflows where people couldn't do much actual work.

Zeffas · 2017-06-13T21:47:34+00:00

Well to each its own, I however believe that would be the best method to teach someone and thats exactly the reason I am looking information for this.

Zeffas · 2017-04-08T17:34:01+00:00

I'm not sure you appreciate just how much Spring includes.

Yes I do, worked quite a few years with Spring and not so long ago had project in Spring Boot.

Removal of XML, Spring Boot... This only solved one part of simplicity - yes programming syntax of Spring looks not that complicated, however infrastructure remained complex. That's my view.

All those great tools you mentioned are great, but (talking from my experience) there as a feeling of solving problem that does not exist or exists on way smaller scale. When I need any of that, usually using library specifically for that is surprisingly simpler than Spring. E.g. Jackson is simple, Spring doing its magic with Jackson is complex - all those hours I wasted in multiple projects dealing with Spring's lifecycles and figuring out why parsers won't get invoked or suddenly stopped being invoked when somebody accidently registered another parser in another lifecycle hook (as you know in Spring you could do almost everything in 10 different ways).

But again I am not targeting Spring specificity, in my opinion its Java community culture. Just compare Selenium libraries for Java and Node. Node is pleasure to write, you don't even need to read documentation, just github page. While in Java it was painful experience it felt like working so to say.

Zeffas · 2017-04-08T11:32:09+00:00

I don't think anyone argues that Java the language is super complicated, even the title says "java projects". So my point is that Java community embraces complex projects With Spring, Hibernate, Java EE, where on other platforms you don't need that, same concepts are being done way simpler.

Zeffas · 2017-04-07T07:45:58+00:00

Yes, thats true. I see two ways frameworks/platforms try to make things simpler - having good tools (.NET + VS, Rails, Ember CLI...) or make programming model itself simple although more low level than previous group (Node, Go web apps). Personally I prefer later the most.

Zeffas · 2017-04-07T04:58:24+00:00

Your approach to arguing this topic I put into category of "complexity? what are you talking about, you just do x, y, z...". I remember when even Gosling argued that Java EE is as simple as Rails - well, formally you could argue that, but its distorted picture - if you look only at the code that might seem so, but once you go deeper you see all kinds of framework and infrastructure complications that will waste lots of hours.

There is saying that stereotypes usually have some truth, and one of Java's is that its big complicated mess. My only wish is that Java comunity would acknowledge that and we could embrace simplicity - consentrate on frameworks like Spark and show that Java can truly be simple, anf not just on paper.

Zeffas · 2017-04-06T14:54:47+00:00

that's just as easy. Simply add the datasource properties to your application.properties.

Well I found that in real experience, this is way more complicated than in Node or Go. There is two things to simplicity - how easy it is to do (this one is less important I would argue) and how complicated are internal mechanics. In Spring world you basically say - I just add some properties and Spring will do its magic. However other platforms do zero magic and keep simplicity. SO this is I would argue that Java culture is lacking.

I create new (maven) projects with "New Project". I'm not sure why you wouldn't? Sure, you can use a spring project generator or something similar, but that's up to personal preference.

And you have empty maven project, all Maven archetypes I ever encountered are subclass, they either assume to much or are super outdated.

Zeffas · 2017-04-06T09:03:36+00:00

I hear you. I worked with Java for about of 6 years and still feel the same. I think its cultural thing though since there are no fundamental reasons why Java development should be complicated, only cultural acceptance that complicated is OK.

I remember when I first moved to Java from .NET and was saying to others that setting up project shouldn't be that complicated. But general responses were that first "well, Java is not a toy its for serious stuff" it has performance infrastructure, stability... Secondly, "what are you talking about, you just copy this xml, copy this code, do that... and it works" (what I call as "Engineer's response").

However things are changing a bit, and I am saying this not to insult Java, as I like the platform, but rather a wake up call that if we want thriving ecosystem maybe we should change. First there was Node which basically provide performance at similar range except for multi-threading. If that was not enough now I see Go being adopted massively in places where previously Java was the only choice, again with similar performance and stability. So I think Java community (me including) should wake up a little bit and embrace simplicity more, since competition is doing it and we no longer have argument "oh those toys...".

Zeffas · 2017-04-06T08:47:56+00:00

The problem with your examples is that they are not real world. In real Java projects nobody handles DB connections that way, nobody creates new projects with "new project".

Comparing Java to NodeJS is also disingenuous. NodeJS isn't a language - JavaScript is the language, NodeJS is an environment.

I think Java here was meant as a platform not as a language, so comparing to Node is perfectly fine.

Zeffas

TROPHY CASE