neRok

I don't read it that way (most of your post I agree with though). I think the point was that before this email, Kindle devices had their own customers, and Apple wanted Kindle as a feature on their products to increase the appeal of iphone/ipad. But eventually those customers started doing all their "kindling" on their apple devices, so now from apple's perspective they think "we are providing you customers/making you a market, pay us". This is what the whole second paragraph is about.

I wonder if it's because a larger portion of the less-educated people were hesitant due to fear, and that was relieved over time (seeing friends and family get it, seeing celebrities get it, etc).

The more-educated people on the other hand may have come to their conclusion after studying the available facts and deciding that a wait-and-see approach would be better. This would therefore suggest that not enough new information/data has be released yet to change their mind (although this might change soon with more countries hitting high vax levels and opening up).

The story might be different elsewhere, but here it is draftsman that make the 3d models and all the associated data, and to do get a job in the industry only requires 1 year of vocational education. To put it bluntly, these aren't the smartest people.

Maybe. 3D models have been used to design and plan projects for over 20 years now (I've been in the industry in Aus for >15 years), and so the bulk of the models are not at fault here (because if these design models were the delay, the construction would also be delayed, but the article suggests it wasn't). But when you want to go to the next level (digital twin), and start modelling every individual light-bulb, tracking it and making it function as part of a "smart system", then things will take a lot longer.

But actually, the article says;

> Despite the huge amount of construction work that has already been completed, many aspects of Crossrail do not yet have an agreed-upon final design. That’s because the complexity and uncertainty involved in building large underground structures means that detailed “fit out” designs are begun only after it’s fairly clear how the space will look.

This boggles my mind. I don't see how it couldn't all be completed at the start. The physical design should have a few flexibilities baked in, so that if the tunnel ends up a meter out of place, or the rail centerline is 200mm off target, the design should be able to absorb it with minimal re-work.

But regardless of the physical layout, they could have mocked up a model beforehand that contains all the necessary "virtual" components. They would have known what rooms/etc were required, roughly how many entities were needed per space (eg, 4 chairs, 1 table, all with data tags). Then when you have a better idea on the physical layout, you can arrange the virtual components properly.

So yes it's possible that trying to be too fancy was a major factor in the delays. I haven't worked in a professional software engineering environment, but I get the impression that at a high-level, construction engineering has similar traps and pitfalls. Just like when coding, engineers/modellers do come across problems with their initial design, and then have to face the choice of implementing significant work-arounds, or "refactor" to something different.

Anyway, at the very start of my 10min of ganzflicker I think I could see some very faint "wireframe" lines of no shapes in particular (just like * patterns), but these went away after a minute or so, and then it was just flashing colours, but the colours kept changing, and they were mostly reds, pinks, blues, yellows. Rarely green.

OP was probably referring to attacks such as ransomware, because if you don't have an anonymous way to receive payment, then there is less incentive to do the crime in the first place.

I go out socialising/partying less now, and am on the PC more (games, projects, etc - most of my interests are on PC). Your advice creates the people in the article!

> “repeated interactions that are nonconstructive, cast doubt, assume bad intent, make unsubstantiated accusations, or otherwise do not contribute to a positive environment have a massive negative impact on the team and working environment.”

I've had experiences where different levels of management within the company (macro level) or project (micro level) have been making what appear to be less than ideal choices. Often this is because they aren't listening to all or the right workers, which could mean they might not understand all of the issue, or possibly that they don't know all of the options/solutions.

Of course, the workers might not understand all the aspects that management does either (which might relate to the quote in the article: "even tough feedback can and should be delivered with empathy"). However, this won't stop the workers that feel wronged or otherwise justified from voicing their discontent to their peers, and so the problem of negativity quickly snowballs. And so a naive solution is to send out a memo with a sentence like my first quote.

But it's a bit of a chicken or egg scenario, because if the management were achieving better results, the workers wouldn't feel negative in the first place.

Simply put, the entirety of 1 "frame" has more data than required, but a CRT TV would hide those "error margins" behind the borders. Your digital capture however has grabbed all the available data, and the pro would have done the same, but they would have then cropped it down to the desired area/resolution. You can see this when you compare the videos side by side, as the baby is "longer" in the pro version.

Regarding programs, Tekla Structures is the gold standard for detailing steel structures, but the price is up there (if you're looking at going it alone). Cheaper options that I haven't used are available from Autodesk for AutoCAD, and another from Bentley for Microstation. I would look at the Microstation option first, because the "core" seems to be better for 3D work than AutoCAD. However, Autodesk does a reasonably priced bundle of programs for the construction industry, which includes some BIM staples like Navisworks.

So whilst I think it is important to protect this history, some of it can't be that important. I imagine that is what the traditional owners also thought when they signed the agreements. The article mentions "significant cumulative loss", which would become a problem when you sign away the rights to the lot.

But in the case of the cave that Rio Tinto destroyed, surely that was significant enough to protect and work around. I know that it wouldn't take long to design around such a requirement, which makes the outcome even more disappointing.

Power is hardly relevant in this day and age, as any device with a decent firmware should be able to handle a ton of files and formats (this wasn't always the case, hence the need for rockbox).

Smart phones have versatility, but you sacrifice a lot on the music side. The audio hardware within the smartphone isn't as good, and it took a lot of years until there was an android player that had the bare minimum of features required by an audio enthusiast, namely lossless support (flac), replay gain, and gapless playback. Additionally, there are now players that run android and have all the "fruit", so the benefits are dimished.

But don't overlook the versatility of a standalone player, because relatively cheap devices like the Fiio X3 II that I am still running have other advantages compared to phone. It supports big sd cards (wasn't always a given on smart phones), has long battery life, has physical buttons (so can be operated without removing from pocket), and also functions as a USB DAC. So, lots of wins there.

I recently started a large project, so did some reading on architectures/patterns like DDD and Clean-Arch. One of the most important points I took from both was to clearly define your domain. But based upon past experiences, I have developed a dislike for "heavy" objects like those used by DDD and ORM's in general. I like to keep things simple, sort of "functional" in nature - what your link refers to as anemic objects. So I have stuck to the SOLID principles, and in particular the D = dependency injection. I've also taken a fancy to RPC style code, so that influences my code. BTW, clean arch isn't too different from the image of Layered-Arch in your link, more of an evolution really.

So here is how I apply my concepts to your problems...

Users want to know the Events they are registered for, and Events want to know the registered Users. You have a circular dependency! But really, the problem to me is that you haven't expanded your domain enough. I think you should have a third entity, something like UserEventRegistrations. Now User's and Event's don't depend on each other, and UserEventRegistrations will depend upon them. No circle!

As per my like for anemic objects, I would have a User model object to hold properties like name, and a UserRepository for doing CRUD style operations with methods like GetByID() that returns a User instance. The same would apply for Event, and something similar for UserEventRegistrations, except it's repository would have a dependency on the User and Event repository so that it can do methods like GetEventsByUserID().

Then to apply this in Clean-Arch style, I leverage whatever statically typed language I am using (Go, TypeScript, etc) to implement interfaces. So I define the domain layer as the model objects, and interfaces for the repositories. For the persistence layer, I would create a concrete implementation of the repository interfaces, and they would return instances of the domain model objects. Then for presentation, I would create a layer that expects to be dependency-injected with a concrete implementation of the repository interface. So my layers are separate, based upon the "contract" that is my domain layer.

Now your example for User.getProfileAsJson() is vague in meaning, but if you wanted to return the data in a different format than the domain model, you could have another layer on the presentation side of the equation that handles this. It would utilise the repositories to build what you need. So your "Profile" might be a single JSON payload containing a User with their Events. Your function would do UserRepo.GetByID(), check you have a User, then do UserEventRegistrationsRepo.GetEventsByUserID(User.ID). Then it would stick it in your payload, and viola.

I've not completed my project yet, but I've implemented some functionality in all layers (Go server pulling data from RDBMS and sending to TypeScript UI), and it seems to be working well. I've also noticed after the fact that my domain layer ends up looking exactly like a protocol buffers definition, so maybe just use those.

So Sun -> Sun = 7 days = 1 week!

OP's mixing duration with a "period" of time.

Other people and the original source mention food rotting because it cannot be picked before it spoils, which is probably a problem. But in the case of these bananas, they have been picked and made it all the way to a sorting facility, and could be sent to somewhere for consumption. These bananas may be worse than the ones that rot in the field, because they are responsible for additional energy and labour expenditure.

Here's a screen shot of a website I never finished from 2003. Frontpage, tables, 3 gifs, ms paint graphics... this site had the works: https://imgur.com/Lulenom

I don't know what your goals are with this though. I don't want to be the bearer of bad news, but to 'genealogy enthusiasts', ie the people regularly spending money in this domain, your website is no more than a toy. In fact, I'm pretty sure that Ancestry.com offers this same tree building functionality for free (when you pay for a subscription with them, it is for the research capability, not the data entry capability).

The actual data model is terrible though, as it was created by the church based on their 'traditional' style families.

However, most programs do not use GEDCOM to store their data (they might use an SQL database for example), but merely as a way to transfer data between programs.

Also note that there is always someone working to make a replacement for GEDCOM. Some of the latest efforts are GEDCOM-X (made by the church again), and the work by [FHISO](http://fhiso.org/). A lot of such projects, eg BetterGEDCOM, get bogged down in 'internal' politics, and rarely get anywhere.