Yea our stuff’s designed for pretty high end unix systems

lmao, isn't that kind of bug (assignment in conditional) a compile error in Java, the language you were actually going to work in? What an awful question to ask. I missed the single = too.

That's funny, at the last job I had where I did a lot of C++, we had the opposite convention - don't use unsigned numbers if it can be avoided. I think the most important thing is to have a convention one way or the other.

Yeah, Java will not compile that (Error: incompatible types: int cannot be converted to boolean). Implicit conversion between int and boolean is a bad idea.

Always using === in JS is a good way to quickly notice a single =. And the linter warns you.

That said - I've wasted a good man-month debugging stuff like if (someCrap = 5) ...

Yeah. In a statically typed language, you shouldn't need a linter to catch typing errors. Catching problems like that is the point of having static typing. I think all later C-style languages (Java and C# for sure, anyway) broke from C/C++ by disallowing implicit conversion of primitives. Call me a grumpy old man brought up on static languages, but I don't think "truthy" and "falsey" are good ideas even in dynamic languages. It must have cost way more time in nasty bugs than it's saved in being able to write if(foo) rather than if(foo !== 0) or whatever.

Is there a generic remote for Mac that can pause, FF and play video in full screen? I'm currently watching gamepass.nfl.com on my TV - through an HDMI connection to my mac. The annoying part is I have to get up to FF, pause or play.

I would have thought there was a cheap generic remote that could do all this. But google and amazon searching is not fruitful.

Yep. But in a dynamically typed language you don't have to spend 4 hours wrestling with how to write a mock class to test a class which takes generics as part of its class signature (or whatever you call that MyClass<InputsT, OutputsT> thing).

Tradeoffs on both sides. Personally having been a Java and JS dev for 10 years+ each - I'll take dynamically typed with linters and stuff to keep me out of trouble. With frameworks like react or a node app - 99% of your run-time errors not caught by a linter are still caught when the app tries to boot or load in the browser. Autocomplete, which is awesome, is the only thing I really miss from statically typed world.


I have a "fun" theory of development. The more fun, the more productive. The less a dev has to worry about stuff like plumbing, or mapping out a complicated class hierarchy with interfaces and stuff before they can start building functionality - the more *fun* they have coding. The more time they can spend on the intent of the thing they're trying to create - the more fun they have. With a dynamically typed language you're pretty much off and running immediately.

When a new feature gets floated and devs immediately start brainstorming about how to make it work, with a positive demeanor, that's a good sign that your architecture is set up well. When devs immediately start expressing pain from all the stuff they'll have to refactor, or tedious config and things they'll have to change - that's no fun - a bad sign imo.

And yes I get that figuring out class hierarchies can be fun. But realizing your beautiful Animal->Human/Dog and Human->Robot class structure is shattered by a request for a Robot Dog - is not fun. Class hierarchies assume perfect understanding of the logical domain - and a logical domain which never evolves - which is basically never the case.

I'm buzzed so not really stating this well. But anyway that's the concept.

My company started microservices in node, and have moved to mostly Java/Kotlin. I'm on the fence. I love node and the expressiveness but helping newbs with promises gets old fast, and holy hell is our bigger service a tangled mess of nightmare fuel.

Kotlin seems really cool and Spring is leaps and bounds above where it was back in 2013 when I was using it daily.

Still prefer node though :P My goodness do Java devs hate JS though. That is all I get to hear all day. How terrible JS is.

And totally agree on testing. Rspec is the nicest experience ever writing tests, with mocha somewhat close behind. Testing Java code sucks and makes me just skip it as often as possible


I will also throw in, the majority of negatives I run into in Node are because it is code written by Java devs who are trying to make it look/feel as much like Java as possible, and then complaining when you can't do X (private methods, interface, w/e). It's a different language!

Could not agree more. I think my issue isnt "Java", it's Spring. Which is a powerful framework obviously, but it's amazing until something doesn't work, and you spend hours trying to figure out why. It ends up feeling more like I am a configuration engineer than a software engineer. I have the same issue with Rails, and walk away with disgust about Ruby, which most smart people I know seem to love. Big, Magic frameworks take away the fun for me I guess.

This article actually articulates everything super well:
https://blog.sourcerer.io/why-is-a-j...t-7cfc423efb44


This dude hates OOP, esp inheritance in general, but this was pretty good:
https://medium.com/javascript-scene/...p-88d71b9b2d9f

Yeah the Java devs at my last job were basically turning most of our node apps into typescript Java apps - which defeats the whole purpose.

Give me any tangled node app and I guarantee I can streamline it down to the bare essentials. Most just don't do it right.

We had a node/express web-app that served some 200 routes, which is about as big as a web-app should ever get, and it was dream. I never once wished I had types, inheritance or more config files.

You and I will never agree about Typescript Optional types / conditional types are the coolest thing to me, because I get a lot of the Node magic without the Java static typing garble

But yeah, we had a monolith Ruby app, and they decided to write this first "micro" service in Node. No one at the company had done Node before, and boy does it show. We dubbed it the Microlith

I'd say that personally I find development in C# more "fun" than JavaScript because of the heavy IDE support, but that's subject to change.

Inheritance is the devil. Class hierachies are, or should be, born of necessity. Objects should be composed.

btw, not sure if you'll have any call for this in the C# you're writing, but I highly recommend AutoMapper, which is a .NET object-object mapper. I don't know if you'll like it or if it'll drive you crazy, because it's a method of trying to avoid one of the downsides of static typing. Very briefly, when you pass data between two domains, or layers, or whatever you want to call them, you typically want to translate one object to another, to keep the two domains encapsulated. AutoMapper provides a low-boilerplate, flexible and testable way of doing this. As one example, if I use normal boilerplate code to translate object Foo to object Bar, but then I add a property to object Bar, I can merrily just not instantiate that property, creating a bug. If I use AutoMapper to do it, that will invalidate the configuration and it will fail AssertConfigurationIsValid() on startup.

I just started at this job so I don't have that much experience with it, but my initial impressions are that it's easier to read, easier to see at a glance what changes have been implemented between tags (so easier to create release notes) and more aesthetically pleasing.

The biggest downside in my experience is that the workflow is more complex so it might not be the best fit for teams with lots of junior devs that just started using git. There's also a segment of devs that believe that the history is sacred and you shouldn't mess with it, but I don't really agree.

Put your User model in a managed SQL store and move on. Using unstructured DBs is perfectly fine for many use cases, but your user model is one the most core core objects in the system. You will want transactions, backups, referential integrity, etc at some point. You scale it in the future by sharding by customer.

The thing is we aren't the system of record for user data (phone, address, email, etc) - the CRM system is. So our user model would be stuff the app specifically needs to keep track of - like preferences and who knows what else in the future.

So I feel like noSql makes more sense as our user model will probably start very small and grow over time.

Tbh I've never been impressed by him. I get the feeling he's one of those people that's very good at promoting themselves and writing good blog posts, but maybe doesn't have as much real world experience as he gives off. And getting hired at Google wouldn't change my view that much, especially since Google will often give "senior" devs low overs like L3 and L4 (the lowest SWE positions).

I'm convinced you're a masochist. I don't know much about git submodules, but a guy in my team did some refactor a while back to eliminate submodules from our legacy puppet system. I did some googling around and found enough posts about how submodules are a horrible thing. I didn't investigate much further but assumed he did it for a good reason.

Yeah I'm ready to pull the cord on them pretty quick after the first disaster.

Write your Java tests in Kotlin

Do you just need a cache in that case? How do you keep this data in sync with the source of truth? How will you handle schema changes? Would you need to backfill data on schema changes? Is your query pattern only lookup by primary key? How experienced are you with noSQL stores? SQL stores obv have issues too but it's the lowest common denominator and scales very well.

There's a batch process every night or so that saves user changes to the CRM. It actually has to be reviewed by humans so they don't change their name to Mickey Mouse or something. Handling that will be a whole other ball of wax. But the team already tried to tackle it once in the past (on their first attempt at this app) so a lot of the business logic has at least been captured and there's old code to look at.

The data which will actually be saved in our app DB will be extra stuff that isn't stored in CRM. Picture a CRM that stores user vital information like address, phone, birthday. But our app stores user preferences - like which page they'd like to view first - and the all important mapping of Cognito user ID to CRM user id. And probably some other stuff we haven't thought of yet.

As far as schema changes - the app will need to be smart enough to treat missing properties as the default value. The way I've done this in the past is to deep merge the user object over the default object, then evaluate that.

Yes only lookup user info by primary key - the User ID supplied by Cognito. The app will never make queries across all users.

Not sure experienced with NoSql but this feels like a good application of it to me.

It's a good point though that I need to decide where to cache the bulk of the user data, which comes from the CRM. Mostly it will be read-only for the app. But we'll need to have it available to every request. Something like DAX - which is a hot caching layer over dynamodb - looks promising. However that means I'll have to save the CRM user data in dynamo - so it can be hot-cached - and then worry about how to invalidate if it gets out of sync. Hmmm

I wrote almost 0 Java. Unfortunately most people use junit so it feels rather similar.

I gave spek a test run back in v1 and was not impressed but I hear spek 2 is way better.

Lots of kotlin in my future currently. My team is trying to standardize on it for everything new

I've been on a number of projects that said they were going to test with junit. I've been on zero projects that made it to maturity with a comprehensive battery of junit tests. I have no idea what that actually looks like.

I want to know how people say the word "junit" out loud