Yeah. In fact, the article linked below[1] is more informative than the page I linked. TL;DR: there’s a big reduction to the overall weight of an EV using these, but they do add to the unsprung mass of the vehicle (the weight below suspension, as mentioned in another comment).
I wouldn't go there. These things are supposed to be helpful, any bug or chance of a bug will be detrimental to their stated purpose, just imagine scenarios were zed tells git to download a repo and you have to make sure it downloads to a linux directory and not a windows directory, otherwise you lose all of the access bits, and it's slow af.
I appreciate your concern and I will consider this.
The [VS Code] WSL back-end has access to things in WSL PATH, like compilers and language servers. I don't duplicate them in Windows, and would like to avoid having double installs. It's also nice to be able to open integrated terminal and use `fish` and other unix-only CLI utilities.
Thank you! Using a pure functional programming language in a game project has been suprisingly easy. I find an event driven, completely asynchoronus architecture well suited for a simulation game such as Liikennematto. Some events are big (a road tile was placed - this will update the tilemap as well as the road network graph), and some are small (UI events). Everything boils down to how an event will transform the game state.
Though many games have been built with Elm, I've had to implement lots of "game engine" code myself. For example, the collision system, physics (acceleration etc.), and path finding are custom code. It's worth mentioning that this is my fist gamedev project, and I've had to read up a quite a bit on the topic. Still the difficult was not in Elm itself, but in math and data structures, as it would be on any language.
Elm's lack of runtime exceptions and mutable state makes any game quite robust. Most of the bugs in Liikennematto have been of omissions (forgot to update something) and in math formulas. 3rd party Elm libraries are often excellent with great docs and have helped along the way.
Lastly Elm is quite performant (pure functions can be inlined and easily optimized) and I can create a single .js file that contains the game code, UI and the assets (which are still SVG in Elm). The whole game is still about 1 megabyte minimized! I think that's amazing, despite not shipping the runtime enviroment (the browser).
This has been a fun (and rather long) project. I craved for a simple city builder that a toddler could play and understand. You might want to start from the first devlog entry to see where Liikennematto came from.
You can play Liikennematto in your browser on itch.io[1] (the link is buried at the end of the article).
I want to share with you this tiny tool that I recently hacked together.
It's trivial in nature - a web version of the Greenwich Time Signal that's often played when a news broadcast starts.
Though you can reset the seconds on your digital watch by visual means (like another synced clock), I think that a sound indicator helps with the timing. With that in mind, this tool fills a very small niche.
The original time signal is slowly being phased out from linear broadcasts, and other official sources are being discontinued [1]. I want to help preserve this part of analogue history in a digital format and provide a fallback.
The Elm programming language ecosystem has the great "elm-units" library, which prevents one from mixing illogical units, and it produces logical unit combinations:
I'm not much of a Spring fan (overengineering) but that's how a mature stack looks like. There were plenty alternatives 10-20 years ago. What's a bit more surprising IMO is the prevalence of Spring MVC in 2020 which doesn't mix well with modern JS-centric frontend approaches, just as splitting frontend and backend work between JS and Java is flying in the face of agile job rotation.
We haven't used Spring MVC since 2015, all our services are running Spring Boot because it is the most mature solution on the market to create the webservice layer. Our Spring apps are then containerized and optimized with jib[1]. Our frontend is built on React Hooks + TypeScript, fully SPA. All the work nowadays in our company is focused on data engineering, by that I mean: databases, parsers, managing the data pipelines, orchestration, Python for creating the models and Java for inference in production, our teams consist of data scientists that are using Python and software engineers that are using Java and TypeScript.
I don't understand why people consider Spring to be overengineered. We find it very productive, time to market is huge and we can focus on other parts of development instead of reinventing the wheel. We are also considering Quarkus for some of our services that aren't supposed to run for a long time.
I'm not sure why they separated them. Spring is Spring imo. There's a lot of tooling that is very quickly accessible and "just works". We have 15 microservices and three or four UIs that are all Spring backend with React frontends and it isn't even a little cumbersome. We don't serve the static content from Spring as a webserver though (we use a separate nginx instance).
Nobody forces you to use it, there are a lot of alternatives out there.
But I have to admit that Spring Boot combined with Kotlin is the most productive development environment I have ever worked in. I am not surprised it is so popular among Java devs.
> Nobody forces you to use it, there are a lot of alternatives out there.
That assumes you're starting a greenfield development. If you're joining existing companies with a mature tech stack, you won't be able to unseat their existing choices because there's a lot of risk involved.
If there is no both WORTH to maintain and hard to maintain code in your language of choice, it's because that language of choice was not used to solve the type of problem Java is used for...
In this current post monolith, micro-service world, most java applications remain very maintainable though.
Actually my language of choice has been used mostly as a Java replacement. And while there is no perfectly maintainable language, little else is remotely close to the awfulness of trying to maintain a Spring Boot application.
Spring boot specifically; regular Spring is relatively ok. I'm using it professionally at the moment. It's just impossible to find where anything is coming from or understand how your application is wired up, because everything magically appears based on what's on the classpath - it's like the COME FROM statement joke. Even just changing your dependency versions can suddenly radically change your application's behaviour (e.g. now it's suddenly running a webserver).
I don't understand why is it better to have something wired up by annotations than explicitly writing java code. Is 'new' obsolete? At least tools (including IDE) can look for method calls, annotation strings not so much.
I'm completely baffled by the popularity of Spring.
> I don't understand why is it better to have something wired up by annotations than explicitly writing java code.
The argument is that most of your services will be global-ish singletons, and so the details of which services are used from which other services are ceremony rather than business logic; if you've made a code change that means service A now calls service C instead of service B, you want the diff to be about the actual code change in A rather than the plumbing of where it's getting service C from. Since there are problems with language-level singletons (e.g. testability) you want to use plain objects passed to the constructor, but since 99.9% of the time the FooService is always going to be the FooServiceImpl, you don't want the trouble of explicitly wiring it all up yourself. I don't necessarily think Spring is worth it, but wiring by hand certainly does involve writing a lot of code that's more or less irrelevant to your actual business logic.
> At least tools (including IDE) can look for method calls, annotation strings not so much.
Actually one of the things that makes Spring almost tolerable is that IDEs generally do have integration with it, and so "find references" will work properly even for things that are reflectively instantiated by Spring.
(That only applies as long as your wiring is "static" though. With Spring Boot's conditional bean annotations all that goes out of the window and you have no hope of understanding where anything is coming from or where anything is used).
I am not sold on the premise that plumbing code is bad or not business logic, being explicit is no trouble, it is part of the story. How is writing a factory method worse than writing Spring configurations? Personally I prefer to write Java to Spring DSL.
The point is you don't have to write the Spring configuration (except in the rare cases where you need to override with something specific). Just mark each class's constructor as @Autowired, make an AnnotationConfiguredApplicationContext passing the list of all your classes, and you don't have to manually keep track of which services need which other services - Spring takes care of instantiating everything in order and passing dependencies into the things that need them.
Annotations make dependency injection simpler. If you have a Controller that has a Service autowired into the constructor then you can test it by passing a mock service into the constructor.
An alternative would be to have a Main method construct all of the objects and pass them into each other, but @Autowired takes care of that for you.
I don't see any problem with that, in fact, being explicit is a huge plus. I would take that any day of the week over untraceable code.
To be more precise, I'm not just baffled by the popularity of Spring, I don't even comprehend how any of that is a good idea to begin with. It solves a non problem and brings in enormous baggage.
That is true, there's a lot of "magic" that comes with boot. It can be helpful to take a look at what all of that auto-configuration code is actually doing, but reading that stuff is pretty difficult as well.
> It can be helpful to take a look at what all of that auto-configuration code is actually doing
You can't tell by reading it either, because it's all dynamic: all of the autoconfigurations create beans conditionally only if other beans of that type aren't defined, if certain classes are present on the classpath, if particular values are defined in the configuration that's written in magical self-transforming YAML, or all three. The only way I've found is to breakpoint at the point where something is wired in to see what the concrete class is, then breakpoint again in the constructor of that class to find where it's being constructed from, so you have to restart your application and run the (slow) spring boot startup twice for each thing you care about. And even that doesn't always work because spring encourages doing AOP with bytecode-manipulation-based proxies.
I went through quite some trouble to get a react-table v6 based datagrid updated to v7.
I found that the examples showed individual features well, but when you combine features you are on your own. The "Kitchen Sink" example is far from having all features enabled at once.
The reason why I couldn't stay with v6 was that the virtualization examples used a deprecated API from an old minor version. I would have had to support a solution on a non-supported version (v6 has been pretty much abandoned).
So, I had to get these features to coexist peacefully:
- expanded rows
- virtualization
- sorting
- custom cell rendering
- click actions inside the cells (open a dialog, add the row entity to comparison)
Mirroring the GP, I had to use react-window and deal with the complexity from the library. I think that virtualization should be a first-class citizen inside react-table, like sorting.
On top of all of this the TypeScript support/typings are tricky to work with (IIRC you have to maintain a .d.ts file in your codebase and remember to update it when you update react-table). I literally had a headache for hours on while going through the refactoring.
In the end I managed to get everything to work without any bugs or weird behavior. I really was enthusiastic about v7, but was left with a bad feel of it.
I'm sure that things will get better, and luckily most folks don't beed all of these features. It's really the virtualization that makes things complicated. The thing is, pagination is not always a viable solution.
[1]: https://www.cnet.com/home/electric-vehicles/this-donut-shape...