It’s one of the topics I feel I’m too biased since I spend 10 years as a flash developer. The requests for widgets and or small applications we got where simply impossible to write in a frontend only fashion at the time. And a lot of my peers moved on to work on HTML5 which was pushed hard as the successor at the time. A lot felt like a step back. I moved to native iOS and worked on games in cocoa 2D. I remember that I thought more than once: “This was already solved in flash”. But I think in the end it’s a good thing that we don’t have or need the flash player anymore. I wish only we could have gotten a flash to wasm/webgl compiler or flash to js transpiler.
ActionScript 3 was great and leagues ahead of JavaScript at the time.
Yup, this was my career path as well. I worked professionally as a Flash developer for many years but gradually that became more of an iOS developer role and I made games using Cocos2D etc.
Not to be too snarky but I really detest teams. We use Slack in our company but the mothership is all teams. Every time I have to use it I spit in anger. It’s the sum of all these weird usability issues etc. so my personal recommendation would be to always say it doesn’t work ^^
Every slack I had to join professionally, the most active channel was the channel for non-work or not project related stuff.
So, I had to use it, ask questions, point out non-working services, while watching the same person's responsibile for the disfunct services share trivia about their favorite animes, sci-fi or whatever crap of the day seemed more important.
Thus, I detest communities having slack as a first point of contact.
Ah well yes. We have this as well but I think it is still under control for us. We fight more the sheer amount of channels. It’s so damn easy to create channels and invite people to channels etc. But that is also true for Teams.
The mirror board is an interesting idea as it allows to start with a normal keyboard and one could then switch to a smaller board with the muscle memory trained. I would prefer a different switch key though. I use cap lock as a layer switch on my keyboards. But I will think about it and try out a few things.
It could already be useful in situation where I need to keep my hand over the mousepad.
Don’t know about the story telling as in a story about the past of the laptop. I have a lot of colleagues who come back with a full plastered laptop the second day they receive a new machine. I think that there is a culture of either leave you machines pristine or show you don’t give a f… how expensive it is. Sure the world is not black and white here so.
I always felt the old matrix had a more colder blue. And it changed drastically when the second and third hit cinemas. At least that was my memory because I watched a double feature when the second one hit the theatre's and complained then that the Matrix somehow looked weird.
But it could also be my memory since I also own the blue ray release.
Another movie with the same / similar problem is the DVD release of the Lord of the Rings Extended editions. Both Blu-ray and 4K version. As far as I remember is that they fixed it for the theatrical version in 4K but not extended.
I think he posts from a US standpoint where regulations for the aftermarket is problematic and adaptive headlights are allowed but with such high standards that no automaker has them yet.
Also LUMEN is a very stupid way to market car headlights as it just depicts the light intensity. Candela is usually used for this specific application since it’s a measurement of light intensity in a specific direction.
Just the other day we tried to explain inner workings of cursor etc to a bunch of colleagues who had a very complicated view how these agents achieve what they do. Awesome post. Makes it easier for me the next time.
The options are so big. But one should say that an agent with file access etc, is easy to write but hard to control. If you want to build yourself a general coding agent a bit more thought needs to be put into the whole thing. Otherwise you might end up with a “dd -if=/dev/random -of=/“ or something ^^ and happily execute it.
I still wonder who came up with the charge your car during the day / use it as a batterie. I don’t have the luxury’s of owning two EVs that I can charge and use at the same time.
If my car stand unused at home so I can charge it would mean I use it during the night?
I understand that there could be useage pattern where someone works from home once or twice a week and waits with the charge during these peek hours. But the generalization of just charge your car during the day is weird.
Unless that also counts when the car could charge for free at the workplace of course.
Obviously it still works great on the weekend, or whatever days you’re not working to charge the EV at home for free.
Given all power is free, why wouldn’t you charge the EV at work in the middle of the day? Even if you pay to have the charger installed it will pay back quickly.
It’s not going to happen overnight, but with literally free electricity things will change quickly, and even huge parking structures or lots will have a stack of chargers that are free or very close to it.
Well, to me the EV conversion push, which undeniably exists and has many government policies supporting it, does represent an agenda, and that agenda is "Cars Über Alles". The obviously more practical approach to the problem is to support the conversion of transportation demand to less energy-intensive modes such as trains, buses, bicycles, and feet. It isn't very practical to say we're all going to have an EV and we'll have plenty of megawatt-scale chargers for everyone.
The liquid fuel distribution system is simply far more space-efficient than any known means of EV charging. The liquid fuel scheme works because the energy flux through the pump is obscene. EVs don't have an answer to this problem.
Is it falling apart right now? It seems the poster has forgotten that EVs can be charged at home but also away from home. They mention that in the last paragraph, but it kind of seems to undermine the whole premise that this is a problem.
I use containers in Firefox and have good to semi good experience. Will try this out. My main issue with containers so far is SSO. I have some things like GitHub etc I like to keep in my coding container. Then domains that only belong to work. But my company uses SSO in GitHub. It makes the usage really awkward. Start in GitHub container, login jumps to Work container and links back to GitHub container and fails since the cookies created by the login container are not set.
But to separate shopping and finance related things it works great. But I will give this a go since I have finally a harder separation between work and private usage of my coding and ai usage etc.
Makes me kind of sad. I started my carrier back in days when XHTML and co were lauded as the next thing. I worked with SOAP and WDSLs. I loved that one can express nearly everything in XML. And namespaces… Then came json and apart from being easier to read for humans I wondered why we switch from this one great exchange format to this half baked one. But maybe I’m just nostalgic. But every time I deal with json parsers for type serialization and the question how to express HashMaps and sets, how to provide type information etc etc I think back to XML and the way that everything was available on board. Looked ugly as hell though :)
json is sort of a gresham's law "bad money drives out the good" but for tech: lazy and forgiving technologies drive out the better but stricter ones.
bad technology seems to make life easier at the beginning, but that's why we now have sloppy websites that are an unorganized mess of different libraries, several MB in size without reason, and an absolute usability and accessibility nightmare.
xhtml and xml were better, also the idea separating syntax from presentation, but they were too intelligent for our own good.
> lazy and forgiving technologies drive out the better but stricter ones.
JSON is not "lazy and forgiving" (seriously, go try adding a comment to it).
It was just laser-focused on what the actual problem was that needed to be solved by many devs in day-to-day practice.
Meanwhile XML wanted to be an entire ecosystem, its own XML Cinematic Universe, where you had to adopt it all to really use it.
It's not surprising to me that JSON won out, but it's not because it's worse, it's actually much better than XML for the job it ended up being used for (a generic format to transfer state between running programs supporting common data structures with no extraneous add-ons or requirements).
XML is better for a few other things, but those things are far less commonly needed.
Don’t know if I would describe it as much better. I see it similar to the whole SQL -> NOSQL -> let’s add all the feature and end up with SQL. JSON undergo a similar story with the difference that we didn’t go back to XML. What I mean is to simplify and then realize what was actually missing.
But I agree for the smaller services and state transfer especially in web XML was just too damn big and verbose. But conceptually it was great.
For "I need this Python dict to exist in this unrelated JavaScript program's context space" JSON is absolutely much better. If only because you completely sidestep all the various XML foibles, including its very real security foibles.
JSON is so good at this that, like CSV, it does displace better tech for that use case, but the better tech isn't usually XML but rather things like Avro or Protobuf.
For the most part people don't add on XML features to JSON. Comments are a frequent addition, sometimes schemas, but for the most part the attraction of JSON is avoiding features of XML, like external entity validation, namespaces, getting to choose between SAX or DOM styles, or being required to support unrelated XML systems just to use another.
Again, there are problem domains where those are helpful, and XML is a good fit for those. But those problem spaces end up being much smaller in scale than the ones solved by JSON, Avro, Iceberg, etc.
But the whole point to JSON is to be nearly as dumb simple as possible so that the complexity of the problem domain will necessarily be handled in a real programming language, not by the data magically trying to transform itself.