goofballlogic

I enjoy social media and use it to exchange information, observe trends in culture, and as a communication channel when convenient.

In my case the null state was "not yet processed" i.e. a decision pending

Exception i encountered recently was needing ternary state boolean. a set of flags where true and false indicates outcome and undefined indicates "not yet processed". I suppose some sort of 0 timestamp could work but... No, I think I'll stick with boolean.

As a human being he wasn't perfect, but I come back to images from his film in my head time and time again and they help me look up from my work and consider bigger things on an ongoing basis. His films create space in my head which I go to for help when I need it most.

It would be nice if we somehow had one to convert typescript back into _idiomatic_ JavaScript.

Agree. I don't use or like tiktok but it's sad to see the internet walls setting in. Inevitable perhaps, but sad nonetheless

One of the hard things to get right when writing one of these "Tips for being a great X" is that they're usually written from the point of view of someone who is a clear leader in their field.

With some exceptions, the people who write this sort of article have the confidence (or presumption) to see themselves as ahead of the pack. It is rare to see articles like this written by teams of people who, in cooperation, balance tasks like product management, architecture, engineering, operations and customer success between them. And yet that is, imo, the best way to do it.

When I read and article like this advising the reader to do X to "their team" (in this case let your team get on with work), it falls into this category where the "how to be a great X" applies to a particular structure - where "X" is somehow in control of the rest of the team, rather than an equal participant.

Is there any indication that the numbering change reflects a significant technical shift (eg preparing to target ARM specifically)? Or is this just aesthetics?

Main thing that would prevent me investing in this stack is that the runtime has been designed with typescript in mind. In a few years if the typescript thing blows over, you're left with a runtime and conventions skewed toward statically-typed programming patterns.

He had his scandals but this guy was a legend. A real defining influence on my teenage years.

While I agree with the concerns regarding arbitrary implementation of standard APIs, there are still a bunch of useful applications of PWA technology to enable temporary offline operation.

The more we use these, the more likely the APIs are to be fully implemented (and hopefully have features added to them).

A sad day I think. I wish more independent ecosystems were evolving, instead of consolidating.

Great idea. I was just thinking about how this would be a great idea the other day.

As a UI architect I've worked on both SPAs and also ROCA-style UI quite a bit. Like everything pros and cons to both.

As a general rule of thumb I find SPAs deliver much faster, but ROCA-style solutions are much more predictable. That is, getting a modest MVP out the door with an SPA terms to be much faster, but almost always reach a critical mass of functionality at which point they become hard to maintain. ROCA-style apps don't suffer with this as much.

I don't think this experience is just down to the architecture however. I just think it asks a lot more of a software engineer to structure and maintain an SPA well. Ultimately an SPA can be a more optimal architecture for many applications because the client-side environment is an increasingly powerful VM in its own right. However, I rarely see the engineering discipline required to do it right.

I tend to prefer ROCA-style because it fits better with the web's distributed integration architecture, but in practice I find building an SPA with a resource-oriented mindset is usually a good compromise.

What happened to Idris? As someone who knows absolutely nothing about Haskell, I thought Idris was essentially Haskell+dependent types?

"an engineer codes what someone else thinks they want" seems a fairly damning indictment of our industry although I think the author meant it tongue-in-cheek.

Lack of ownership of responsibility is still quite a big roadblock for many companies.

That had been my conclusions over the years. Erlang (or Elixir) are ironically one of the nicest environments for OO code these days (given they are usually categorized as "functional")

I think this is an issue which needs to be addressed a bit more holisticly. The fact is that HTML, JavaScript and CSS (to name three) all use an element's _className_ for slightly different purposes.

The author seems to consider BEM an example of a _semantic_ CSS scheme, but really the semantic needs to be clear across all the consumers of the API being implicitly established by the markup.

Ultimately HTML is the original source of a web page, with CSS and JavaScript often augmenting this. For that reason, I think it makes sense to opt for the HTML spec's definition of _className_ semantics when there is a clash.

The spec effectively balances the importance of both CSS and JavaScript (or other user agent) uses, but cites an example useful to both:

https://www.w3.org/TR/1999/REC-html401-19991224/struct/globa...

Does anyone know if the author completed other projects in Ada (or another language)? I'd be interested in reading some code as well as the specs.

I too struggle to like AMP. The rhetoric seems a little absent imagination in regard to offline. Are you really saying your handheld computer can't be useful without a worldwide network connection?

Love reading this stuff. When I grow up I want to be a C programmer.

Strange article. The add-on libraries described aren't necessary at all.

Being "a Manager" is the wrong first step to leading a team. Management is an activity we should all be undertaking, not a role.

I do hope that this works. One major concern I have is being badly burned by using Xamarin when it was a couple of years (4?) old. I hope they don't do that to github. Xamarin wasn't very elegant back then when those guys started it - it was a horrid hack. That makes me worried.

I try not to do this as I never bought into the idea of evolving a prototype into a production app.

My first prototypes tend to be in create-react-app with session-storage (state dies with browser session). I publish this as entirely static content on Amazon S3 (via CloudFront).

After that if the use case seems solid I choose the appropriate tech for the job

I try not to do this as I never bought into the idea of evolving a prototype into a production app.

My first prototypes tend to be in create-react-app with session-storage (state dies with browser session).

After that if the use case seems solid I choose the appropriate tech for the job

I have to agree with @rado on this one. The article presents this as a "code" vs "UI" debate when really it's a "web" vs "app" debate.

Although we use the web as an application platform, it was designed for information interchange, and evolved to support "an Internet-scale distributed hypermedia system." Those are often two quite different things. An application platform focuses on "component semantics" whereas the concept of an "Internet-scale" application focuses on "connector semantics".

"Not only is the set of input controls really small, but these controls have almost no functionality associated with them." - yes and that's a useful attribute if you are architecting "internet-scale" applications (think hypermedia, rest, hateoas et al.) because the intent is that each component is dumb enough to be seamlessly switched out with another. In this mindset, a page in a web application does one thing and does it well. It doesn't coincidentally provide retina scanning and 3d imagery (yes, i know...)

Neither the code nor the UI of the web are "solved" problems if you are trying to use it as a traditional application programming platform. You need frameworks and tooling to accomplish that.

I'm not arguing here that it should be this way (although I happen to love the web concept), but the real debate here is about "web" vs "app" - not "code" vs "UI". HTML is designed to facilitate web applications and that will continue to evolve very slowly and deliberately. The alternative is to reimagine web technologies as a traditional application platform from the ground up.

There's still an opportunity for Microsoft to fix this. They definitely have major problems with basic functional requirements at the moment (like reliably displaying messages that another person has sent to you in chat), but there's not really another offering out there with the brand associations that the Skype name comes with.

All they need to do to bring people back is simplify and focus on robustness of the key functions. However, I'm not sure there's much of a business model they could exploit in this way. Using Skype is free. I've used in for about 10 years and in that time I've maybe spent £40 on paid calling. That's not enough to sustain a high quality offering. It only works if consumer market is the entire focus, leveraging the strategies that the like of Facebook employ.

For these reasons, although it wouldn't be hard to fix, I reckon it won't happen. But who knows, Microsoft have done some things in the open source arena over the last five years. Maybe one day they'll run a product like Skype simply for the satisfaction of owning the world's best online calling service (and the money would surely follow).

A json-based format still has some advantages depending on context. E.g. JavaScript code can manipulate JSON data "natively" whereas XML support is far harder to achieve.

Awesome stuff. I'm working with JSON-LD in both C# and JavaScript and loving the freedom that the linked data concepts (constraints) bring to developing APIs.