dhd415

This question is orthogonal to the question of whether ABA accreditation is beneficial.

This is a better article on the topic explaining that the ABA's requirements for different forms of diversity oppose the administration's ban on DEI. It also points out that this could lower the cost of law school by reducing superfluous requirements for law school accreditation.

https://www.reuters.com/legal/government/texas-becomes-first...

My longest employment stint was at such a company and it was a very good experience for me. That said, even though I worked at such a company for a while, I don't have a very good idea how I would go about identifying other such companies with open roles. Any suggestions on how to do that?

Organizations such as the ACLU and the American Red Cross are registered organizations and I doubt you'd advocate for restricting or redefining their civil rights. Perhaps you'd draw the line at for-profit organizations, but that doesn't make it better. Should Ben & Jerry's or Patagonia or other corporations with notable positions on social issues not enjoy the protection of civil rights from those who oppose them?

The bottom line is that any restriction or redefinition of civil rights is fraught with negative unintended consequences. It should be an option chosen with extreme care.

There are certainly legitimate concerns about the influence of Amazon and other large corporations, but the solution is not so simple as what you suggest. Corporations are associations of people, so you are advocating for civil rights for individuals up until they associate with others and act or speak collectively. That would be radically detrimental to the meaning of civil rights.

As a previous comment noted, Elastic _did_ take them to court over the trademark and it was _not_ thrown out: https://www.elastic.co/blog/elastic-and-amazon-reach-agreeme...

I've found my moderately-priced Eaton 5S 1500 unit to perform considerably better than any of the non-pro APC models I used before it.

This. I finally switched from using various APC models to an Eaton 5S 1500 unit for my desktop and a couple peripherals and it's much better while still being comparably priced.

I would say that infrequently used tools are an especially good choice for battery-powered cordless tools when the alternative is typically a tool powered by a gas small engine. For example, I need a chainsaw for infrequent jobs, but every time I ran it, I'd have to fiddle with the carb and the spark plugs, throw out old gas, make a new gas/oil mix, etc., so it was a major pain and I'd use it only if I really, really needed it. I replaced it with a 36v Makita chainsaw and it's a breeze to use every time.

This is most definitely true, but I think it highlights the mistaken idea that individual healthcare is a commodity. I think we all recognize that an excellent home builder, auto mechanic, attorney, software developer, etc., can have an outsized impact on the outcome of potentially severe or expensive situation but we often put less effort into finding a healthcare provider for a particular malady. I've had some severe negative outcomes from questionably competent, focused-on-billing doctors where I would have been better off not seeing a doctor at all than seeing them. Unfortunately, there's no reliable way to separate the truly skilled doctors from the ones who barely passed their boards.

Their X Compact line of phones was great with high-end SoCs and incredible battery life but unfortunately, they haven't released any new phones in that line for several years so they're pretty dated now.

Doesn't appear to be available yet for Chrome in the Chrome Web Store or for Android in the Google Play Store, either. :(

Taking this approach to using a database is always a judgement call, but putting logic in the database is probably useful a lot more often than the "nine times out of ten" that the article claims. And the tradeoff in this approach contradicts the last line in the article: "Utilize the full extent of your database’s capabilities, but don’t put domain logic in it." Putting logic in your database is often necessary to make full use of its capabilities.

In applications with complex storage needs and/or performance-sensitive IO needs, I prefer to think about databases as an additional tier that provides complex storage services (as is precisely the case with most modern databases). As an example, I once worked on message routing and transformation server. From the perspective of the application logic, messages simply needed to be durably persisted and retrieved. At the level of the storage layer, I wanted message versioning, provenance, copy-on-write semantics to minimize on-disk size, and indexes to support at least two different retrieval patterns. All of the items at the storage layer were implemented in stored procedures. In other words, the database supplied a custom "storage API" to the business logic tier for persisting and retrieving messages that implemented those routines in a database-specific way that did not concern developers at the application layer.

The main arguments against this approach are:

* It will tie you to a specific database. This is true, but almost irrelevant since anything other than the most trivial usage of a database will inevitably make use of a feature or syntax specific to the database that would require modification were one to migrate to another database. Further, the mere idea of database independence is kinda' silly. No one talks about how writing your application layer in one particular programming language will limit the ability to migrate to another programming language. We should make technology choices around programming languages, databases, etc. with the intention of matching their strengths to the problem at hand fully understanding that tradeoffs are being made and that rework will be necessary if those choices are ever revisited.

* SQL used for writing stored procedures is not as good (for some definition of "good") as other programming languages used in the application layer. SQL is certainly different than most imperative or functional programming languages, but it's expressive and well-suited for its purpose. If you really need to make use of the capabilities of a database, it would behoove you to develop some proficiency in SQL.

* Putting logic in the database breaks modern CI/CD processes. IMO, this is the most compelling argument against it. That said, there is tooling that exists for putting stored procedure and other database logic in version control, automatically deploying it to a database, and running tests on it. These tools are not as commonly used, but they do exist. I've also used tooling that introspected the database objects such as stored procedures, etc., and automatically generated type-safe application code to interact with those database objects. That provided compile-time guarantees that application and database code were in sync at least with respect to number and types of arguments, etc. Whether it makes sense to go to the effort of integrating this tooling into your development process is a judgement call, but it can be done and I've seen it work well for application with demanding database needs.

I've operated MySQL in production at different scales ranging up to _very_ large and as such, I place a lot of emphasis on how well that can be done. I posted some of this a couple years ago, but I would describe the production operation of MySQL as a minefield. I maintained a list of the mines I stepped on and here are the two I encountered with the biggest blast radius:

* If you have pre-5.6.4 date/time columns in your table and perform any kind of ALTER TABLE statement on that table (even one that doesn't involve the date/time columns), it will TAKE A TABLE LOCK AND REWRITE YOUR ENTIRE TABLE to upgrade to the new date/time types. In other words, your carefully-crafted online DDL statement will become fully offline and blocking for the entirety of the operation. To add insult to injury, the full table upgrade was UNAVOIDABLE until 5.6.24 when an option (still defaulted to off!) was added to decline the automatic upgrade of date/time columns. If you couldn't upgrade to 5.6.24, you had two choices with any table with pre-5.6.4 types: make no DDL changes of any kind to it or accept downtime while the full table rewrite was performed. To be as fair as possible, this is documented in the MySQL docs, but it is mind-blowing to me that any database team would release this behavior into production. In other words, in what world is the upgrade of date/time types to add a bit more fractional precision so important that all online DDL operations on that table will be silently, automatically, and unavoidably converted to offline operations in order to perform the upgrade? To me, this is indicative of the same mindset that released MySQL for so many years with the unsafe and silent downgrading of data as the default mode of operation.

* Dropping a table takes a global lock that prevents the execution of ANY QUERY until the underlying files for the table are removed from the filesystem. Under many circumstances, this would go unnoticed, but I experienced a 7-minute production outage when I dropped a 700GB table that was no longer used. Apparently, this delay is due to the time it takes the underlying Linux filesystems to delete the large table file. This was an RDS instance, so I had no visibility into the filesystem used and it was probably exacerbated by the EBS backing for the RDS instance, but still, what database takes out a GLOBAL LOCK TO DROP A TABLE? After the incident, I googled for and found this description of the problem (https://www.percona.com/blog/2009/06/16/slow-drop-table/) which isn't well-documented. It's almost as if you have to anticipate every possible way in which MySQL could screw you and then google for it if you want to avoid production downtime.

There are others, too, but to this day, those two still raise my blood pressure when I think about them. In addition to MySQL, I've pushed SQL Server and PostgreSQL pretty hard in production environments and never encountered gotchas like that. Unlike MySQL, those teams appear to understand the priorities of people who run production databases and they make it very clear when there are big and potentially disrupting changes and they don't make those changes obligatory, automatic, and silent as MySQL did. IMO, MySQL has its place for very specific workloads, but if you don't have deep enough knowledge of DB engines and your workload to know that yours is one of those specific workloads, you should default to PostgreSQL.

It's certainly an accomplishment to achieve a highly productive per capita economy, but I don't think it's quite the slight on the US when the four countries with higher productivity per capita range in size from 0.3% to 2.8% of US GDP. Achieving productivity per capita at scale is hard.

I've experienced a very similar effect. The health ROI on your time investment with strength-focused training is pretty incredible. If you could bottle it up and sell it, you'd be rich!

This article is focused on growth in muscle _size_ over growth in muscle _strength_. The two are related, but it's pretty well-established that you can bias your training towards one or the other. You can see the difference between experienced powerlifters and bodybuilders. PLs move heavier weights than BBs, but the latter generally have more muscle mass. I think training for strength has more everyday health benefits than bodybuilding and its training methodology (train large muscle groups with high weight and lower reps ~2x/week) at the novice and intermediate level is much less time-consuming.

In the theme of the OP and by way of response, I've been lifting weights for decades but only in the last couple years realized that gloves were detrimental to lifting. They add a layer of material around the bar that increases its circumference and thereby increases the effort required to grip it for pulling movements. They reduce your tactile connection to the bar which is important for engaging secondary muscles in certain lifts (e.g., lats in the overhead press) as you progress in strength and for very technical lifts such as the clean. The only time hand protection may be beneficial is for movements in which your hand rotates relative to a bar. That is never the case for a (properly performed) barbell exercise but may be the case in certain gymnastic movements on a pullup bar and in that case, you might consider gymnastics grips.

Yep, this prompted me to uninstall the snap version of Firefox that was installed by default in Ubuntu 22.04 and reinstall it from the Standard Ubuntu repository. Score minus one for snap.

You're right that $200K won't buy a house with a pool in most desirable parts of Texas, but your quip about $1M houses in Frisco is misleading. Frisco is not just a "random suburb nobody outside of Texas has heard of." It's a very desirable suburb on the fast-growing north side of the DFW Metroplex.

My work issues me a MBP that I can't stand, so finding a way to access it remotely has been a priority. For CLI apps, I SSH into it from a Linux machine, but for GUI apps, I've tried X (most Mac apps are Cocoa and not X-compatible), NoMachine (it was ok), Splashtop (ok speed but glitchy), VNC (slow), and Jump Desktop (https://www.jumpdesktop.com). I found Jump Desktop to be surprisingly good, roughly on par with RDP. They have a free version, so I'd recommend you try it.

You're right about more gears in auto transmissions helping to keep the engine at its ideal RPM for torque. There are still more mechanical losses in an auto transmissions since the auto transmission's fluid-based torque converter does not transfer engine rotation as efficiently as a manual transmission's friction-based clutch when the latter is fully engaged.

In terms of technological advances, the automatic transmission is a tenuous improvement over the manual transmission. It costs more to manufacture and service and it performs less well (transfers engine torque less efficiently to wheels and cannot anticipate the need to upshift or downshift) in exchange for requiring less skill from drivers. The newer sequential manual transmissions (SMGs) blend the benefits of both with the mechanics of a manual transmission but shifts performed electronically. They're great except that they cost even more. I, for one, am happy with my old, reliable manual transmission.

In addition to the manufacturer, the type of appliance and its manufacture date really matters. I have an LG front-loading washing machine from the late 2000s that has been working fine for 14 years with one minor circuit board replacement. My appliance repair guy says that LGs from that timeframe are very reliable. When the motor bearings on that washer go out, I'll have him replace the motor if OEM replacement motors are available rather than buy a new one.

Refrigerators are a completely different animal as are dishwashers, etc. Despite my great experiences with LG washers, I'd avoid LG refrigerators. I've had good experience with multiple Bosch and Miele dishwashers, but mediocre experiences on all the new fridges I've bought in the last 10 years.

It's a long story, but not exactly. Elasticsearch was developed independently by Shay Banon in 2010 and a couple others who are the founders of Elastic (http://www.elastic.co) under the Apache2 open source license. In March of 2015, Elastic acquired Found, a company offering cloud-hosted managed Elasticsearch clusters which became their "Elastic Cloud" product. In October of 2015, AWS launched their own managed Elasticsearch service called "AWS Elasticsearch Service". Werner Vogels announced it in a now-deleted tweet saying that it was a "great partnership between @elastic and #AWS" when, in fact, there was no partnership at all (thing https://www.theregister.com/2021/01/21/aws_not_ok_says_elast...). In January of 2021, Elastic changed the license under which Elasticsearch was developed from Apache2 to the "Elastic" license which allowed essentially all the same things as Apache2 (free use, modification, etc) so long as it was not used to provide a managed offering of Elasticsearch (https://www.elastic.co/blog/licensing-change). This was done because Elastic viewed itself as developing the Elasticsearch product that AWS immediately took and used for its own "AWS Elasticsearch Service" in competition against Elastic's own Elastic Cloud service which was a significant source of revenue for Elastic. Additionally, Elastic sued AWS for trademark infringement for the use of the "Elasticsearch" trademark in the "AWS Elasticsearch Service" name. In response, AWS forked the last Apache2 release of Elasticsearch and named their fork "OpenSearch". They also changed the name of their managed offering to the "AWS OpenSearch Service".

During the same timeframe, many other companies have seen the same risk of AWS taking their open source products and providing competing managed offerings and have chosen various methods of protecting themselves from AWS competition. Many of them (including MongoDB, MariaDB, Confluent, CockroachDB, Sentry.io, Apollo, Graylog, Couchbase) have adopted licenses such as the SSPL, BSL, and even the Elastic license that prevent or strongly discourage AWS from using their products in a managed offering. Others such as Grafana Labs have partnered with AWS (under undisclosed terms) for a managed offering. It's an ongoing tension between companies that want to offer an open source product with a managed offering that monetizes it.

I feel like a lot of the criticism and dismissals of management and corporate meetings like this unfairly and naively denigrate the value and importance of corporate strategy and processes in nearly the exact same way as engineering work and processes are often denigrated and misunderstood by non-engineers.

Early in my engineering career, I had the privilege of being personal friends with the older CEO of my company who was very much a business/corporate type but valued engineering as well though he was not an engineer himself. He was able to help me see through several product cycles that sales and marketing was, in many (or even most) cases, more pivotal to the success of a product than engineering. That's not to say that engineering does not matter -- it does, especially when it comes to scale and technical debt that affects release velocity, but the end customer in 99.9% of cases does not care about the engineering behind a product, only whether it solves their problem. The business and corporate meetings (when done properly-- there can be complete BS business/corporate stuff but that's a matter of incompetence) should focus efforts on delivering what customers need. Seeing that first-hand gave me a much greater appreciation for other disciplines within successful companies as well as some humility around the magnitude and importance of my contributions as an engineer. It takes all kinds and the talented business types who can proverbially sell ice to Eskimos are force multipliers akin to the mythical 10x engineer and worth their weight in gold.

I think it depends on how many FB posts you've viewed already. It didn't require a login for me until I refreshed twice.

I agree. I don't see any way that Bolt benefits from having outstanding loans to employees for early option exercise, so all this criticism of them seems misplaced. Say what you want about their business model, valuation, etc., but this looks to me like an honest attempt to help employees with early option exercises. Stock options are risky at any juncture, but I appreciate having the option to exercise early as the tax benefits can be substantial.

>I'm somewhat blown away by this whole thing. Leverage to finance an already-leveraged derivatives position on illiquid stock. From the issuer of said stock. Who is also the borrower's employee. That's both risky and dodgy!<<

It's risky, but not necessarily dodgy. Many employers do not even permit early exercise and I wish more did as I could have substantially reduced my tax burden in some situations. Taking loans for early exercise is risky, but ultimately, we're adults who are responsible for our own decisions. Certainly it would be bad if Bolt misled employees into thinking it was a risk-less proposition, but I've not heard anyone claiming that.

>Bolt positions the "below $200,000" sum as a win. I don't see it that way. That's below the lower bound of the accredited investor income test. The people taking out these loans by legal definition couldn't afford the risk. Yet Bolt doubled down and gave them leverage?<<

If the aggregate loan amount to laid-off employees was $200k, that says nothing about whether they qualified as accredited investors. Further, the accredited investor designation is an arbitrary one. It's perfectly possible to not be an accredited investor and still be able to afford the risk of early option exercise.

I suspect that lots of people ask for O(n) when they mean Θ(n) instead which specifies both an upper and lower bound. For example, specifying Θ(n^3) as the running time for a bubble sort would be incorrect whereas O(n^3) would be imprecise but not incorrect.