That's a high bar - in my experience (New Zealand) 1/3 of candidates can't even write any form of code to retrieve a random element from an array. 1/3 have to be nudged along and asked some leading questions, and 1/3 are "what the heck are you asking me that for, I can do that in my sleep, that better not be indicative of the quality of coders... "
There is just so much misrepresentation out there it's insane.
I hear these complaints a lot - and feel like the unspoken problem is your HR or recruiters are non-technical and shovel garbage candidates at devs to sort out. Whenever I've had (technical) engineering managers involved with reaching out and reviewing candidates, we rarely have misrepresentation or fakers.
The PT-P models (we've got and a lot of our clients use the PT-P900W) - it does a very nifty "half cut" on laminated tape labels that makes it super easy to peel and stick.
Love the API it has, aside from some quirks - we can control the printer from within our Android/iOS apps - literally can tell it to half cut the labels or not.
Wow so you work at CDK. I wouldn't wish the sh-t storm you guys must be going through on our worst enemy.
I was talking with one of your clients today (we're not competitors) and you just don't realise how far screwed some of these companies are right now.
It actually made an instant upsell today of 'here's our additional cloud sync' feature. No questions, no umming and ahhing, it's just 'yep done, add it, turn it on'. Heck we probably undersold it by 10x.
I hope you guys start getting some sense of normality soon and get systems back online.
Close to this market - ShopMonkey is doing it for general garage work, and we, GlobalWorkshop, are doing it for high end/custom vehicles (restoration/restomods/small motorsport teams).
I'm pretty sure one of our recent trialling companies have been using CDK and desperate to get away from it for their restoration work.
"It hasn't been updated in years" was the quote last week..
30+ years in the software industry. Everyone did this back in the day - then it changed for 3 reasons (1) completely unsustainable (2) people didn't upgrade, or being forced to upgrade and pay large prices got grumpy about it. (3) the money people figured out subscriptions were more profitable.
There's tonnes of companies that have legacy 'pay upfront' models, that hit the wall as they'd saturated their markets, then their revenue stream dropped off and all of a sudden saw the wall of transitioning to web/mobile needing to happen and didn't have the funds to pull it off.
I'd almost completely forgotten about it until I was challenged by a prospect in a meeting monday 'is this one of these new lease software systems, I want to own it!" had to educate him on the way the world worked now...
We just had ANZAC day in NZ [commemorating WWI/battle of gallipoli). A bunch of (I'm guessing younger people) are getting up in arms that it's glorification of war and whataboutism on other things going on the world "why don't we do x about y", "we shouldn't be celebrating it" etc etc.
They really missed the point that it's about not forgetting the brutality of war - to remember those who served and died under horrific circumstances. One of the key phrases is "lest we forget". However I fear we are, as each generation passes from WWI/WWII the horrors gradually get diluted.
While we don't have kids it's apparent the younger generations are not getting the stories of WWI/WWII passed down and their exposure to it is the glorification through Hollywood.
Thank you good HN'er for posting this up. It's always important to remember so we as a world don't go back there.
On the theme of Dan Carlin and generational dilution, the first episode ever was an interesting exploration of how Alexander and Hitler through that lens.
It's completely different to the current audiobook like format, but the early episodes are still well worth a look.
I was on a 32in 5k ultrawide.. trying out a 42 4k oled just now. My eyes are thanking me for the bigger screen realestate, but I did get used to the wideness of the UltraWide. Definitely better to go massive single in my view.
That OLED video look though, just can't be beaten..
I would imagine with cutbacks on spending/investing I think people getting leaner and meaner will re-visit the sheer productivity you can get out of it.
Sure shaving the last 10/10ths of having a SPA with simple API based back end gets the ultimate user experience and speed but that cost curve goes up significantly for that last 10th (if you were to compared to an 'old school' Rails app)
I can't even fathom what it would have taken to build our startups' product in say React + Node (as an example..) vs OG Rails SSR. I look at a "sort of" competitor in our industry, and their rate of feature development is ridiculously slow by comparison.
> I look at a "sort of" competitor in our industry, and their rate of feature development is ridiculously slow by comparison.
Seconded. At my org, Ruby/Rails is our competitive advantage.
Our 5-6 competitors are all Java/.NET shops -- we deliver fixes and new features dramatically faster and deploy them with ease. It gets noticed.
The main downside is rails doesn't scale well re: complexity so regular refactors are necessary (ours is a high-volume big data app).
For performance/cost, it took some doing but by strategically moving business logic to higher performance techs we've even managed to get to a great spot there.
While certainly a little polarising the adage of optimise later really comes into play here. We do a lightweight industry specific system that had all the generic stuff (eg time/tasks etc) with some special sauce that makes us stand out. One of our clients said "Mate the rate you guys are adding features - the ERP company we went with they haven't done 1/10th of what you've done in the last year. Can you implement full multi-level bills of materials? "
I said "no, can't do that - that's huge".
A weekend later of experimentation (thanks to one very kick-butt gem on that has an amazing way of managing trees) "actually, we may just be able to - it's going to be a long road though - setting expectations..."
A period of time later we've now implemented a full BOM planning/tracking system, tested well upto and beyond the numbers of items these types of companies expect.
To the point they cancelled their renewal with a big/established ERP vendor and went with us instead.
There's definitely some instances where speed to market trumps everything else. We can go optimise queries later on.
What's been fascinating is I left my day job 2 years ago (to the month). We've gone from unheard of to becoming the market leader in our space. There is absolutely no way that could have been done with any other stack (without spending 5x the money - and I argue that co-ordinating a bigger developer team it almost wouldn't matter what money you throw at it, it gets exponentially harder getting everyone on the same page for delivery).
At my old workplace I couldn't convince the .NET team for love nor money to look outside the box.
Because Ruby and especially RoR is a strict downgrade in every dimension compared to .NET. Now, these developers could have been using old .NET Framework, in which case we usually pretend they don’t exist because it’s like stubborn Python 2 of .NET that is otherwise the most productive platform for back-end (with really, really good performance).
> Because Ruby and especially RoR is a strict downgrade in every dimension compared to .NET.
And that line of thinking is damaging in the tech world. There is no one ring to rule them all. Each tool, language, framework has a place - everything has tradeoffs.
I've worked with enough .NET world to know what the tradeoffs would have been.
For instance the critical library that enabled this piece of functionality, the nearest thing in .NET world looks to have 1 star on github, last updated 4 years ago. The ruby gem has 1.8k stars, tonnes of commits and upto date.
So if you were to implement that in .NET you would be (a) hitting the books (b) re-writing that library or (c) doing a hugely in-effecient/naive implementation that wouldn't scale.
In RoR land - drop in the gem and be prototyping that afternoon.
Sure if I was VC backed, and had money to burn, it might be a bit more interesting to use .NET - if were targetting more enterprise oriented clients and potentially wanted an on prem option, then yeah - .NET. Wanting more access to developers in our country - .NET, that's the predominant market. Etc etc.
Ruby is subjectively a worse language than C#, it has worse tooling (as testified by Ruby developers), worse expressiveness and, most of all, much worse performance.
If there isn't an SDK for something in .NET but is in Ruby, it speaks for the poor quality of an engineering culture in that company (as it is likely they offer Java SDK at the same time). And even in that case, you can just generate a client from OpenAPI manifest. Or a gRPC client from .proto (even better). Or if it's an algorithm, you're much better positioned with all the low-level tools C# offers to write something performant with reasonable amount of effort.
And even if that doesn't work, you can just call C bindings by using one of many existing binding generators or just `[LibraryImport]` the calls directly with little effort, after all, C# is a proper C language with C structs and pointers.
But most importantly, you get robust results and consistently good performing application with no scalability issues, good build system and very little risk of accidentally breaking the codebase.
And you don't need to make a developer productivity tradeoff in order to achieve that. I don't know when the bad reputation has to go away, but surely we're long past that point.
I will admit that the .NET ecosystem has gotten way better since being more friendly towards Linux users/environments and I used to code a lot of C#.
I love both Ruby and C# - I don't think one is better than the other. Ruby also has good interop with C. The performance of Ruby is good enough for most use cases. Scaling a Ruby app via multi-process scaling has worked perfectly fine without major issues for most use cases. The open-source 3rd party libraries in the Rails world have a certain "feel" to them.. as if they were written by devs that care a LOT about the - excuse the trendy term- DevEx that are often missing in the C# world.
Call it bias due to familiarity but Rails continues to remain the most productive option to bootstrap a web app/startup for me. Often I think most of the dissonance is simply due to difference in philosophy. Devs don't like Rails because its not "their way" and not that it is inherently better.
Pick the tools you like to use, most productive with, and most appropriate for the application - thats it. No need to nitpick on language semantics, tooling, or performance if those are not even major considerations for what you are building.
If you haven't given Turbo and Stimulus a shot, I would recommend it. Way faster to write than React, and super fast and performant. I would say its definitely the way to go with Rails pages that aren't extremely simple.
Could you share the kinds of situations in which you've seen Stimulus and Turbo really shine?
My team inherited a Rails app, which used Turbo and Stimulus and we really struggled to create UIs that matched our design team's vision. We eventually had to move to react + MUI just so that we could build a webapp with a modern look and feel.
None of us come from a rails background, so I'm sure that a big part of our problem came from us trying to bend Rails to our will rather than embracing it - if you have any advice on articles / books that embody the rails approach, I'd be really grateful if you could share them.
How Stimulus and Turbo work together, is basically this: Turbo lets you do partial page updates. Stimulus works a bit like a super light framework for UI only functionality (Toast messages, Error notices, etc). We have made both applications that are pretty stateful and more display and read only, and its way faster to both develop and run than React pages imo. Compared to standard ERB pages in Rails, where if you want to change some value on the page, you need to reload the whole page. Turbo lets you split these up into components with their own controllers, and views, and components. Then only reload the components you need to reload. So you end up with a lot more performance, a lot less redraws, and a lot less database activity for complicated pages.
I remember what happened in the early 2000s and how companies pulled back on the tech they were using. A few years ago I was convinced that fat front-end stacks are a luxury of companies with "free" money, and that the industry would be making tough choices. (To be clear, there are applications that the SPA approach is best for, but many applications are being built that could just as well be served by an old-school PHP and Jquery app)
I feel like this opinion is a bit stale, many companies use tools like NextJS, and it's as productive as Rails and not what I'd call "fat". The biggest issue some folks have are there's no standard ORM yet (maybe Prisma), but ORMs are not so critical with node or js based apps imho.
I do like how NextJS has done a good job of bridging the gap between SPAs and classical back-end apps (for example, file-based routing). My understanding (with limited experience) is that the deployment story is great for Vercel, and less so for other platforms (requiring you to own a lot of the build pipeline, which is one of the bigger pain points of modern JS)
It was done before ORM became en vogue using SQL and recordsets. When it got too hairy we'd just put an abstraction in place, similar to how many apps end up doing the same atop the ORM via service objects, etc.
Given the choice I bet there's going to be surprisingly large number of orgs go "we'll take n+24hrs thanks"