Was playing around with the #Zed IDE from Zed Industries this evening.There's no Windows installer for it yet but you can compile it pretty easily.Yesterday I updated my #Rust toolchain, and with Visual Studio Community made sure the MSVC C++ build tools and Windows 11 SDK were installed.I let `cargo run` do its thing while I did other stuff, and when it eventually finished, it just launched without any build errors. Love that.Still early days though, it's not yet the most intuitive to use. I do like the docs as they are now, and also the familiar keybindings from VS Code. I wonder how easy a complete newcomer would find it though.The idea of built in #collaboration features for the IDE is great. I first saw this kind of feature many years ago in JetBrains #IntelliJ IDEA, where you could do things like viewing a colleague's session and diffing files against their local copy. I thought that was amazing! We've also seen it in recent years in Visual Studio Code and VS proper with #LiveShare.One thing these kinds of tools have issues with usually though is challenges within corporations - networking policies, proxies and firewalls, data privacy policies, etc. Having an ability to use an on-premise/local server for this would be nice too I think. As far as I understand, you can run a local collaboration version, but it's just a dev tool at the moment more than a product.The ability to follow collaborators is useful for #remotePairing or #mobProgramming.Channels with a side-by-side chat window, and note links to Markdown notes is nice. I haven't really used all the features fully, but I think it might support voice?Since COVID days I've wanted a way to combine something like Discord with Live Share or MS Teams, where you can enter a "room" with your colleagues/team, similar to being in an open office while working on-site, but now working remotely. Need a break, go over into the "coffee corner" virtual room and see what people in there are chatting or talking about - whether its collaborating on something, or just socializing. Need to have a quick team breakaway discussion, use another room/channel.Having AI as another "collaborator" in the IDE is of course nice. Interesting to see the support of multiple language model integrations too.I've recently been wanting to get back into the command line world as a primary environment, and like that it has built in vim emulation (yes... I'm finally wanting to figure out how to be a vim power user... maybe).Glad to see there's a #csharp extension, as well as an #asciidoc extension, think I might be testing those pretty soon :)Looking forward to not just playing around a bit, but trying it out on a proper project, to see how it performs. zed.devhttps://lnkd.in/e5Shjx8P

2

What is a TypeScript Engineer? I keep seeing this pop up in recruitment posts, which means clients are asking for it...right? Has this replaced the FullStack Engineer, which, lets be honest, meant a NodeJS developer. That was back in the good old days when it was only NodeJS. Now we have Bun, Deno, Hono and more. Or perhaps its asking for a Javascript developer...whatever that means in todays world of a thousand js frameworks and evolving ES standards.Or are they actually asking for a Java developer, because someones used Gen AI along the way and it got confused between Java and Javascript (*shudders*)Are they seriously in need of a type system engineer, thats kinda niche.It's hard enough trying to explain what you do as a job to "normal" folk as it is, without this level of obfuscation. How would you even explain this when asked "What do you do?". Do kids nowadays needs to consider themselves experts in everything inside package.json to land a job?When will the industry move beyond this fixation on specific languages? I get it, it's an important consideration, but asking for Typescript Engineers...it's not going to help you find the devs you actually need.

14

7 Comments

I thought it might be fun to start a bit of a LinkedIn Challenge - to meet 100 Developers in 100 DaysI've been a C#/.NET software developer for over 2 decades. I've actually been coding with the .NET Framework since one of its beta releasesPost a comment of what your primary coding language is and how long you've been mastering your craft#softwaredevelopers#coders#100devsin100days#linkedinchallenge

2

I'm working with a team in Go and they have these "err != nil checks" everywhere. To me it's a really big smell. I'm not familiar enough with Go to know better though. Feels like in the InitialCall if there's an error a Functional Null Object Pattern should apply. Any Golang experts want to offer up some constructive help? Note, everything has been abstracted out, so don't try to make too much sense of what the code is doing.

347

406 Comments

TypeScript 5.5 – It's a Banger!It's been slightly more than two weeks since the release of TypeScript 5.5, and if you haven't explored the latest updates yet (just like me 😊), I highly recommend checking out this insightful video by Matt Pocock [https://lnkd.in/gdVeWBni]The new features include Set methods, regex syntax checking, inferred type predicates, and many more exciting additions. My favorite update is the new tsconfig template variable configDir, which enhances support for monorepos. Setting up those three levels of tsconfig used to be quite tricky, and this update makes it significantly easier.Check out the full release notes here (https://lnkd.in/gNKy-5F7).What's your favorite update?#TypeScript #TypeScript5_5 #JavaScript #WebDevelopment #Programming #Coding #SoftwareDevelopment #TechUpdates #DeveloperCommunity #Angular

23

📝 New post on my blog“What's new in ECMAScript 2024”There are a lot of great features added to the specification this year, but some of them are very nuanced and outside of the commonly used set of tools by day-to-day app makers. I did my homework, and I tried my best to explain them all using simple practical examples. Enjoy reading and have a good week folks.https://lnkd.in/e35kw_zk#javascript #ecmascript 

2

this is a really important point.Of course it's allowed! the only people I have met with that interpretation of tdd are people who have been forced into it by people who think it's the simple act of writing tests first that matters rather than the mindset that makes you realise doing otherwise is likley play.I think it's really important.When code works according to the spec we should be allowed to ship it. that doesn't mean we are finished - just hit the bare minimum standard.Then we should be allowed to invest more into it and ship it again, and again.This whole madness and obsession with tickets gets in the way of the feedback loop of determining value, shipping and exploration with the consumer of the code.The tests are the *most* important part of a codebase.I can rewrite code but I can only rewrite tests whilst the domain knowledge is clear in my mind. Tests are the source of truth for the behaviour of the system. After that point I depend on the tests to replay it to me.So refactoring and development of tests is a noble persuit that I think many teams and engineers undervalue.

1

Still on the lookout for a new C# developer contract, although hoping that hunt could be over this week, in the meantime I've been busy working on my own idea for some saas software.Added a little bit of intelligence to my prototype and some basic functionality backed by oauth. 4 apis and one azure function built using the onion architecture pattern and TDD with an Angular 17 shell application with the packages functionality imported from a micro front end for the front end.12 pipelines built publishing my libraries to my private nuget, just started on building out my azure infrastructure, and will be building the CI/CD pipelines for deploying my apis, function and 2 angular sites over the course of this week. I have an opportunity to get some real world usage over the course of the next 3 months that I can use to flesh out the functionality for real world use cases and data/telemetry gathering, and begin to think of considerations such as service discovery, setup Azure App Configuration and production ready what I have created such as the oauth login process and tenant signup workflows. This should give me an opportunity to flesh out the ACL within the system as well as work on the UI and start to consider containerisation and getting that into the project early on if I can.The market may be quiet at the moment but I'm staying 100% match fit. (It is the Euros :))I could only get the gif to be accepted by stripping out the frames so apologies for the speed

14

It's 1st December already, which means it's "Advent Of Code" time again (https://lnkd.in/ebrUApNx). I've been taking part since 2021, and whilst I've had greater success some years than others, I've always really enjoyed doing it. Sometimes, day-to-day coding at work can end up being a bit of a repeat of using the existing components to do something or just modifying existing code to add some functionality. It's good to have the opportunity to start with a blank sheet of paper (or an empty file in an IDE) and try to solve a completely new puzzle from scratch. The puzzles are also sized quite nicely, so it's not too arduous if, after solving the puzzle the first time around, you want to go back and try again. It can also be a good way to learn a new language. In 2022, it coincided with me having just been made redundant - as well as being a great distraction from that, some of the jobs I was interviewing for may have needed Python, so I was solving the puzzle first in Typescript/node, then trying to write the same solution in Python.Anyway, I'm a big fan and I definitely recommend giving it a go!

4

One criticism of "strict TDD" is that you're not allowed to add tests after the code's complete. I don't recognise this version of "strict" TDD.If the tests I'm left with from TDD-ing code aren't giving me that warm, fuzzy feeling, I'll explore more, maybe write more tests (or refactor to data-driven or property-based tests if it really has to work, or grab a colleague and do guided inspections if it really, really has to work, or even a proof of correctness if it really, really, really has to work. Whatever gives me sufficient warm fuzzies, basically).As far as I'm aware, after ~25 years of doing and teaching TDD, that's allowed. Not just allowed, in fact, but recommended. 5/5 on Tripadvisor. Would go again.And likewise, if I think, going forward, I don't need some of these regression tests, I'll remove them or consolidate etc. The tests that drive our design often correspond to good regression tests, but certainly not always. More work usually needs to be done. Once the design's in place from TDD-ing the code, we're in the realms of something called "testing", where tests we add are expected to pass first time (though they might not, and that's a good reason to do it). Oh, and this is probably a good time to mention mutation testing. I'll routinely mutation test new or changed code and if that throws up gaps in my regression tests, I'll fill them.

292

54 Comments

📢 📢 📢 The electorate has spoken! The next Workshop Wednesdays session (3 July) will be on Kotlin coroutines and concurrency. How much do you know about scopes, contexts and jobs? What really happens in a suspend function? I've updated the listing and you can sign up right now (https://lnkd.in/dNY6MCgG), it's free and takes place online.Thanks to all 209 of you for taking part in the vote! We'll do the other sessions soon too, the Bluetooth probably next, as that came second (and it's suuuuper fun).#androiddeveloper #kotlin

20

Why do I favour practices like developer testing, TDD, refactoring and continuous integration?It's to enable rapid & sustained evolution of production-ready software.The odds of delivering the right thing in a single pass are so remote that many iterations are likely required. And even when we hit the bullseye, it's almost always a moving target. Not least because putting software into an environment has a tendency to change that environment and the problems we need to solve.

43

Something that landed unnoticed: Playwright support in the Angular CLI 🚀We've been collaborating with the Playwright team to land this community schematic by Jean-François Greffier and Cédric Exbrayat in the CLIPick between Puppeteer, Playwright, Cypress, WebdriverIO, or NightWatch!#angular #typescript #programming #webdev #webdevelopment #javascript #webperformance #webtesting

905

35 Comments

Threaded GUIs - in general don't do it.I regularly see posts bemoaning that here in 2024 we still have single-thead GUI toolkits. I've been seeing similar posts for a long time, and have had discussions at work about why Java Swing has an Event Dispatch Thread for all GUI events.This post is simply a reminder to myself on the best references as to why. But it goes down to this: people at Sun, who had more experience with threads and multi-CPU than just about anyone at the time, tried many times and never made it work reliably.Here are the best posts as to why:Sun VP Graham Hamilton. https://lnkd.in/eSRfFMmDJava Concurrency In Practice9.1. Why are GUIs Single­threaded? ...Multithreaded GUI frameworks tend to be particularly susceptible to deadlock, partially because of the unfortunate interaction between input event processing and any sensible object‐oriented modeling of GUI components. Actions initiated by the user tend to "bubble up" from the OS to the application ‐ a mouse click is detected by the OS, is turned into a "mouse click" event by the toolkit, and is eventually delivered to an application listener as a higher level event such as a "button pressed" event. On the other hand, application‐initiated actions "bubble down" from the application to the OS ‐ changing the background color of a component originates in the application and is dispatched to a specific component class and eventually into the OS for rendering. Combining this tendency for activities to access the same GUI objects in the opposite order with the requirement of making each object thread‐safe yields a recipe for inconsistent lock ordering, which leads to deadlock (see Chapter 10). And this is exactly what nearly every GUI toolkit development effort rediscovered through experience....

2

Interesting paper about property based testing in real usage. Looks like as with any written tests it can help devs have clarity on their solution specs and helps document code. Harder to implement but more valuable when in place.https://lnkd.in/g_UEJvXW

5

Developers who wish to cultivate a reputation for pragmatism can often be heard reminding themselves and others that programming languages, frameworks, practises and guidelines are only "tools", useful to us only insofar as they help us achieve our objectives. They do not often go beyond this to the following question: what is a tool?A tool is something that extends and modifies our powers of action. We can do things with a tool that we could not do (or could not so easily do) without it. In learning to use a tool effectively, we adapt our practice to it: it becomes an intrinsic part of how we do what we do. It takes a while to get used to a tool, to reach proficiency in using it; and changing tools, even for better ones, can initially feel like losing hard-earned skill.I often reflect on a line of Alan Perlis's: "A language that doesn't affect the way you think about programming, is not worth knowing". It's not entirely true: knowing Kotlin hasn't changed the way I think about programming very much, because its differences from Java are mainly ergonomic; they're still very much worth having. But the point that knowing a language can affect the way you think about programming is important. I'd go further: there are some ways of thinking about programming you can only really acquire by working in a language that makes exercising those ways of thinking an intrinsic part of how you get things done in that language.That's my first objection to the "only a tool" line: our relationships with tools are quite deep actually! We get attached to them not only for superficial reasons like brand loyalty, or less superficial reasons like feeling ourselves to be members of a community of shared practice, but because they can profoundly shape our practical outlook, our sense of what is within reach of our abilities. We often think of this as a limitation: "to a person with a hammer, everything looks like a nail", but to a person proficient with a hammer, the ability to fix things or even profoundly reshape them by tapping them in just the right place is a living part of the way they respond to the challenges the world places before them.My second objection comes from the "tool analysis" of the German philosopher Martin Heidegger, who drew attention to another facet of tools: the fact that they sometimes act not as extensions of our practical capability, but as impediments. A hammer breaks, a shopping trolley develops a wayward wheel. We have to fight with our tools when they fall out of working order; but when this happens, something about the tool itself is revealed. Our sense that it is mere equipment, "ready-to-hand" in Heidegger's terminology, is disturbed, and instead it becomes something that we address ourselves to as "present-at-hand", an object or mechanism that must be inspected, debugged, repaired. Abstractions become concrete when they "leak". We should not be dismissive about this experience either - it summons our attention to reality!

12

2 Comments

Great to see that CDDO / GDS have updated their guidance page on the use of Progressive Enhancement on UK Government services 😍https://lnkd.in/esuSVb29Keep fighting the unnecessary bloat that JavaScript has brought to the modern web! ✊#a11y #accessibility #webperf #progressive #enhancement

95

7 Comments

"if you choose the microservice architecture, (the important challenge to solve) is how to properly define your service boundaries, e.g. see https://lnkd.in/dFHQypGv and https://lnkd.in/g_v4ZC9jGiven that the community is _struggling with fundamentals like loose coupling and modularity, which Parnas wrote about in 1972, I suspect it will take a while before we collectively make progress_ on more complex design topics."

There were other examples of this around the web, but none explained _how_ automatic reloading worked in Django. Some implementations felt half-baked. I think this one stands apart.This is also my 70th blog post on DEV 😮https://lnkd.in/gtC6sBMr

3

2 Comments