I am with you. Been messing with tools my entire life...have tried ratcheting screwdrivers of several kinds...Hard no. If I do lots of screws, I use a drill or impact driver. Or, failing that a nice 1/4 or 3/8 ratchet wrench with the appropriate adaptor + bit.
Front page of the .pdf shows a neat lumber gauge in action. It's designed to fit on your finger and allow rapid checking of common dimensions. You can still buy these...or, in this case, an excellent reproduction here: https://www.leevalley.com/en-ca/shop/tools/hand-tools/markin...
I recall this fondly when it came out. I had a few racks of Sun servers at that time...and anyone I showed the video too were convinced it was bullshit. April Fools anyone? However, Brendan and Bryan know their onions...and all the naysayers had to pause and think a bit. It too crazy to believe...and too crazy to not believe. I miss this stuff.
Edit: This was done when everyone ran spinning media. I wonder how modern SSDs hold up?
"National Automobile Dealers Association (NADA), the new-vehicle department of a car dealership accounts for about 58% of a dealership's total sales but less than 26% of a dealership's total gross profit. "
"So where does the majority of a dealership's profit come from? It's not from car sales, at least not directly. It's from the service and parts department, which accounts for the other 49.6% of the dealership's gross profits, according to NADA"
My comment was based on what I have been told by people in the business. They all want to get cars out the door...and raw counts are more important than margins on each. I would say that any new car under warranty will absolutely be serviced at the dealer. After that? Agreed...people will find alternatives. Mind you, in my experience, only "car people" tend to find non-dealer service...many feel "safer" at the dealer. I am told that the manufacturers of the cars make the most profit on a new vehicle sale...not the dealer. This is also why the lease/used market is so attractive to dealers.
I don't really doubt the numbers...in fact, I thought them a bit low. My feeling is that this will really change the automotive landscape for the overall lifecycle of a car. Seems to me that the dealership currently doesn't worry too much about immediate margin on a new car. They know that that car will come back to them for in-warranty service (which the dealer bills back to the manufacturer) and after-warranty service (loyal customers afraid to go to a less expensive garage). In a nutshell, all the real money is the recurring revenue for service. EVs will require less service...so I'm thinking the dealer will just keep their margin higher up front to make sure they don't lose after the sale. I would bet the dealers would rather sell some sort of EV that needs frequent/predictable/reasonable service...thus supporting the annuity model that has existed for decades. What to do? Build super high quality EVs that need almost no maintenance? Then you don't need that expensive dealer network. But consumers want that dealer to visit and complain to when things don't work...and that costs money. In the end, I think consumers will need to realize that their overall experience and expectations of car ownership are in for a big shake up over the next few years.
I am surprised I had to scroll this far to find a dBase reference. I am the same vintage as OP, and yeah... back in the day dBase was the key to riches...at least as a contract dev. I remember spending A Lot of Money on the big box of dBase IV when it was released...all the diskettes and manuals. Around that time there was much talk about migrating from dBase databases (those .dbf files) to the magic of "SQL" which at the time meant nothing to me. Needless to say dBase IV cratered, and the industry went elsewhere. Good times!
Interesting. It was never an issue for us, as we were close to the CC servers. Some folks were not, so they ran their dev/build locally ("network close" to th CC servers) and VNC'd in from their actual location. In that case, only the stuff on the screen had to transit the "far away" network. Although, I think today, network issues would be less of a thing...as I tend to think that networks have scaled faster than code base size. I could be horribly wrong about that though. Any centralized repo is going to have this challenge though. It also depends on if you prefer snapshot or dynamic views. Snapshots were much easier on the network, at the expense of consistency. I also remember the CC team could work magic at optimizing things if you gave them time and a bit of flexibility. Crappy config specs were hard to read, and often slow to work off of. Any config spec that I had to scroll...I knew I was in for a shit week.
I wish I could answer this. I have always had a penchant for any robust versioning system. Even the simple ones (CVS and the like) were amazeballs to me at the time. 20 odd years ago I spent a lot of time with ClearCase (initially Rational, now Rational IBM). I was amazed at what could be done. We had dozens of customers, maybe 3 major and 10-14 minor versions in the field, and probably dozens of "bug fix" or "special customer branches". Oh, and likely 2 or 3 on-going major version dev branches. Somehow, it all worked. If you could describe (by whiteboard or hand-waving) what you wanted to see as your working branch, it could be done. "Give me a view that is exactly what customer x has, but for this directory, give me latest, except for this file...I want that one from customer y" . And blam! The CC guys would make it happen. The magical config spec. I have had to dabble in many other SCMs.. SVN, Git, etc...and they all seemed to be a compromise. Or, just ran out of gas when the going got tough. In my mind, I wish I could argue that ClearCase was where it was at, and the patterns it supported would be wonderful to have today...especially over Git. But I don't know enough to defend the point. All I am saying is that even with enormously complex version scenarios, the damn thing didn't break and we all got our work done.
Thanks. Scar tissue sometimes breeds insight. In further conversation on this phenomenon, I would argue that "long lived databases" are not so as result of brilliant design. Rather, it happens because the database itself is neglected and largely misunderstood, and gets less investment. And they live on and on...managers come and go...no investment. And then, years later, some poor bastard is stuck with a hideous mess that can't go anywhere. Don't let this happen to you.
If I publish a stored proc as an API, it leaves me free (within reason) to alter the actual SQL supporting it. Like modern API design, as long as you don't remove functionality, then change it as required.
I would be having words with the DBA about this. If there is a DBA. No DBA I would hire would allow this silliness. At least not in the actual application schema.
Noticed I said "limit", and not "eliminate". The concept of NULLS in an RDBMS has been discussed and argued for decades. Three valued logic is generally not well understood, and as such, it's usually skipped over. Binary logic is easy...0 or 1. It's there, or not. OFF/ON. 3 valued logic introduces a third state: "unknown". It really means that there is no meaningful answer...not yet, anyway. In simple terms, NULL in RDBMS is dangerously often equated to 0 (zero) in numeric fields. Or "space" in character fields. Neither are true. On occasion, these might behave as such...but you are playing with fire here. What's worse, you can't compare a NULL to a NULL. NULL != NULL. Which is why you often see the "IS NULL" operator used in DML for such things. What it boils down to is that your applications need to pay careful attention when digging around (read: joining) tables with NULLS. Additional code logic is often required to ensure that things work the way you expect them to when NULLS are involved. Formal primary keys cannot NULL (this is enforced by the RDBMS) but it does not stop ad-hoc clever queries from including NULL columns as part of the "where..." clause. So what do? You can tell your DBA to ensure that all columns are NOT NULL. This really tightens things down, and makes some operations a bit more sane. However, if a column value is actually not known (yet!) then one is forced to populate it with data that may not be correct/relevant. These are often called "sentinal" values and can cause a mess of their own. There are use cases where a RDBMS schema with everything as NOT NULL can make sense. In my experience, databases whose data is never (directly) seen/input by actual people can work. When a human sees a field with "placeholder value" instead of just blank space..it is uncomfortable. My advice is to really understand why something might be NULL, and don't blindly add a mess of columns to a table as NULL because it's easy. Remember, that shit will live forever. Google around for "three valued logic" and start down the rabbit hole. Long-term (think: migrating from one RDBMS impl to another) you will absolutely find that NULLs don't behave the same. Various operations may or not be consistent from one to another...and this will break your apps. The key (haha) relationships modeled in your schema...if you strip all the unimportant stuff away...should avoid NULL. The flip side of this is to do a code scan (app side) and search for "is NULL" , "is NOT NULL" in the embedded SQL. Especially when there are a lot of "and ____ IS NOT NULL and ___IS NOT NULL" and so forth. This will indicate those parts of the database that are "hot spots" for NULL issues. I have seen SQL where 80% of the DML is taken up with NULL handling of some kind.
Ok, story time. Worked on a near-real-time system that processed millions of rows an hour. Devs routinely did a "select " and pulled 100K rows into an array on a local client. And they sorted it there*. The DBAs never looked into these because a)no resource issue, b)no perf issues and (most relevant) c) no one complained. One day this silliness was identified, and a quick meeting with the devs and DBA resulted. SQL 101. As if by magic, the client app was suddenly 3X more performant. The devs were applauded and there was much happiness in user-land. Only the SVP knew the truth...we left the sun shining on the developers. It was a rough week.
I share this sentiment. The apps will come and go, the real value is in the data. If the database can cover its ass, I am less concerned about ham-fisted developers randomly messing it up with ill-conceived DML. It's not that they are malicious...it just happens. I have seen devs that code in Erlang, Haskell and even Assembly...run in terror at doing some SQL. It's weird. Trust but verify. And hire persnickity, passionate DBAs.
This is a double-edged sword. I have seen massive business logic baked into stored procedures...so much so, that the applications themselves are rather slim. If this stored procedure code is properly versioned and otherwise managed, this is not entirely bad. If the data model is sound, I don't worry that much...stored procs vs 100KLOC of Java code? I can tell you what is easier to migrate. The other side of it is that stored procedures can also serve as an API into the actual database. I built a system once (90's) where the developers never accessed the actual database tables directly. They always called stored procedures. The advantage here was that we could tune the snot out of the database without a code change/build/deploy. It also allowed the DBA some control over poorly written, runaway queries. YMMV. I think today I probably would try to keep the database as vanilla as possible.
>the database is almost always the main cause of any performance issues
I would be careful with the term "cause". There is a symbiotic relationship between the application and the database. Or, if talking to a DBA...a database and its applications. Most databases can store any sets of arbitrary information...but how they are stored (read: structure) must take into account how the data is to be used. When the database designer can be told up-front (by the app dev team) considerations can be made to optimize performance along whatever vector is most desired (e.g. read speed, write speed, consistency, concurrency, etc). Most database performance issues result when these considerations are left out. Related: Just because a query works (ie. returns the right data) does not mean it's the best query.
This article is informative. I have found that databases in general tend to be less sexy than the front-end apps...especially with the recent cohort of devs. As an old bastard, I would pass on one thing: Realize that any reasonably used database will likely outlast the applications leveraging it. This is especially true the bigger it gets, and the longer it stays in production. That said, if you are influencing the design of a database, imagine years later what someone looking at it might want to know if having to rip all the data out into some other store. Having migrated many legacy systems, I tend to sleep better when I know the data is well-structured and easy to normalize. In those cases, I really don't care so much about the apps. If I can sort out (haha) the data, I worry less about the new apps I need to design. I have been known to bury documentation into for-purpose tables...that way I know that info won't be lost. Export the schema regularly, version it, check it in somewhere. And, if you can, please, limit the use of anything that can hold a NULL. Not every RDBMS handles NULL the same way. Big old databases live a looooong time.
Love this analogy. As a Canadian...we have the same monarch, but our own Constitution / elected officials. So...we are ourselves in the sudoers file...but surely we are different under this analogy than our UK brethren? What are we a VM with sudo root?
I don't think so. Certainly, EBITDA is part of any story. What I was trying to convey was that Broadcom very much wants their customers to be engaged in a strong subscription model... big, recurring license agreements. Customers who, year after year, can be relied upon to send Broadcom money...even if they buy nothing new. Broadcom likes those Big Companies who can be counted upon to spend a consistent (but never shrinking) amount every year. Hock is ruthless in this...and has a pretty good bullshit detector... again, he probably makes a lot of people uncomfortable.
Nothing wrong with that approach... it's very pragmatic... especially for shareholders. Broadcom might give you more for your money every year, but you will never spend less of it.
I still have my MP2000, and it powers up just fine. Although, it could handle year 2000...it seemed to hit the wall from a date range perspective soon after. Anyhow, I was soooo stoked at the time to get one. Back then, there was not a small, useful, handheld device. People that carried them were weirdos. I doubled-down and carried a giant Moto flip-phone too. As fun as the Newton was, it never became my killer device. Why? No one else had one. I could not easily share all that clever stuff I had in my Notes or my Calendar. I firmly believe that if more people had them...you would have seen more adoption. Casio made a few very colourful WinCe devices, too...same fate. And they were huge... may as well carry a real computer...a laptop.
As soon as cell phones got "apps"... calendar especially, then I knew PDA's were dead. When iPhone was launched...well, I knew that it was the smaller, smarter, more connected Newton that was imagined way back then.