throwaway201606

I appreciate this clarrification comment: had originally read this as option B and was wondering "why would they say this?"

In software dev, for a big finance corp

I like your comment, want to try to expand on it

Comment long but there is a TL;DR at the bottom

My theory is that there are 4 areas to domain knowledge worth taking about here - there may be more but I like 2*2 matrices

1) explicit internal requirements - core of how the how the app should work towards achieving your business objectives - code expresses what should be done and to a pretty large extent, why it should be done - from business unit requirements - we are building a tool to do “X”

2) implicit internal requirements - core of how the how the app should work towards achieving your business parameters and constraints

eg profit = selling price - ( total of costs )

  - code expresses what should be done but really can’t express why. At best it is in the comments 

3) implicit internal requirements - core of how the how the app should work towards achieving your business constraints - code expresses what should be done but really can’t express why. At best it is in the comments

eg if item is “rocket” , shipping = $1m ( we only make rockets in Antarctica and shipping from there is $1m)

4) implicit external requirements - core of how the how the app should work towards achieving your business constraints - code expresses what should be done but really can’t express why. At best it is in the comments

eg if item is “rocket” , add a 3 month gating stage to get approval from government to sell the item and do not collect payment till gating approved - AI can see the code but has no idea why it has to be done

These come from partners, regulation, compliance, auditability etc

So, my theory

AI can be good at the explicit stuff trivially (1, 2) but cannot be good at the implicit stuff (3,4)

It might be able to figure out implicit stuff needs to be done but will probably not be able to figure out why it needs to be done and it will definitely not be able to definitively figure out edge cases for when to do it / not do it

As long as you focus on implicit stuff, you will be fine for a little bit

TL;DR - become good and keep being good at being the person who understands the implicit external drivers of software dev

The language of global commerce and technology has not and has never been English

It is money.

Specifically, right now, petro-dollars. For a while before that, it was pounds

The writer is asking how much longer that will continue to be true that it is petro-dollars.

https://en.wikipedia.org/wiki/World_currency

"Sure, but the difference between one particular formulation of mineral oils and another cannot possibly be that important to the formula."

Formulation matters and is very important.

A1 jet fuel, propane, regular 87 gas and vaseline are four different formulations of some version of mineral oil (petroleum).

Which do you want in a car you are driving? On your parched lips? In your plane engine? Coming into your kitchen stove?

They stop growing a full amount of low value subsistence crops needed to survive and start growing cash crops on some portion or on all of the land. Those cash crops have a higher value.

An example - say you have 4 acres of land and have a family of 4.

In the old world, say you needed one acre per person to grow enough food to the next crop harvest. This would be something like corn or potatoes that can keep. So all your land goes to growing food to survive and you cant make any money.

In the new world, with irrigation, you can do much more - say for the sake of argument, 4 times the crop, in the same space. Now, you only need 1/4 of an acre per person or an acre for everyone. So you grow vegetables that sell for 10 times as much on the 3/4s of land you have that you no longer need to use to survive.

Or even better, you grow high veg on the entire piece of land for income and use the cash to buy your corn and potatoes or whatever as you need them.

Just as all other commercial farmers do across the world.

In other words, solar allows them to become small business owners.

Answers here

https://learn.microsoft.com/en-us/azure/cloud-adoption-frame...

TL;DR version - its about money and business balance sheets, not about technology.

For businesses past a certain size, going to cloud is a decision ALWAYS made by business, not by technology.

From a business perspective, having a "relatively fixed" ongoing cost (which is an operational expense ie OpEx ) even if it is significantly higher than what it would cost to do things with internal buy and build out (which is a capital expense cost ie CapEx), make financial planning, taxes and managing EBITDA much easier.

Note that no one on the business really cares what the tech implications are as long at "tech still sorta runs mostly OK".

It also, via financial wizardry, makes tech cost "much less" on a quarter over quarter and year over year basis.

just saw your answer - we are thinking exactly the same thing but I took the long-winded route to saying it

There are many setups where this is not just not possible. In some cases, doing this is prohibitive because of cost or prohibited by law.

+ for case of cost: lots of very large companies have prod environments that cost big $$$. Business will not double prod cost for a staging environment mirroring prod. Take an example of any large bank you know. The online banking platform will cost tens if not hundreds of millions of dollars to run. Now consider that the bank will have hundreds of different platforms. It is just not economically feasible.

+ for the case of law: in some sectors, by law, only workers with "need to know" can access data. Any dev environment data cannot, by law, be a copy of prod. It has to be test data, even anonymization prod data is not allowed in dev/test because of de-anonymization risk.

Given this, consider a platform / app that is multi-tenant (and therefore data driven ) eg a SaaS app in a legally regulated industry such as banking or health care. Or even something like Shopify or GMail for corporate where the app hosts multiple organizations and the org to be used is picked based on data (user login credentials).

The app in this scenario is driven by data parameterization - the client site and content are data driven e.g. when clientXYZ logs on, the site becomes https://clientXYZ.yourAppName.com and all data, config etc are "clientXYZ" specific. And you have hundreds or thousands of clentsAAA through clientZZZ on this platform.

In such a world, dev & test environments can never be matched with prod. Further, the behaviour of the client specific sites could be different even with the same code because data parameters drive app behaviour.

Long story short, mirroring staging and prod is just not feasible in large corporate tech

Me: let's watch the animation to see this in action ...

sees: "an uncursed food ration"

This is wild; I gotta start playing text based games.

The piece is good but I think the primary segmentation is not 'useful' vs 'valued', it is strategic vs. tactical.

The author actually realizes this but did not nail this idea to the church door as part of his manifesto.

      >Being valued, on the other hand, means that you are brought into
      >more conversations, not just to execute, but to help shape the
      > direction. This comes with opportunities to grow and contribute
      > in ways that are meaningful to you and the business.

The second part - "opportunities to grow and contribute in ways that are meaningful to you and the business." - that is being 'valued strategically'

      > Being useful means that you are good at getting things done in a
      > specific area, so that people above you can delegate that
      > completely. You are reliable, efficient, maybe even
      > indispensable in the short term. But you are seen primarily as a gap-filler,
      > someone who delivers on tasks that have to be done but are not
      > necessarily a core component of the company strategy. “Take care
      > of that and don’t screw up” is your mission, and the fewer
      > headaches you create for your leadership chain, the bigger the rewards.

The second part, "Take care of that and don’t screw up” is your mission, and the fewer headaches you create for your leadership chain, the bigger the rewards." is being 'valued tactically'.

So, the theory is every member of staff is dropped BOTH a 'useful' and 'valued' bucket for tactical work and for strategic work.

ie: - one can be useful or not useful for strategic or tactical work or both - one can be valued or not valued for strategic or tactical work or both

A couple of counterpoints:

1. You can,unfortunately, be useful strategically and not be valued. Think about the hachet man every leader of a large organization has - the guy who does the layoffs. That slot is useful strategically but can be filled by almost anyone - it is not valued by the org.

2. You can, fortunately, be useful tactically, useless strategically, and be be very very valued in an organization. Best examples of this are folks who are very very good at running operations. Think about a good truck dispatcher, or a 911 operator or an air traffic controller. 90% of their job is effective tactical execution - dealing with this emerging situation right now effectively and efficiently. That is highly valuable to organizations.

Also note that every org needs strategy people and tactical people for long and short term.

One is not better than the other. They are just different.

And there are lots of very highly paid tactical roles, sometimes better paid, that are more challenging and more interesting than any strategy role.

These tend to be "do this or fix this thing right now efficiently and effectively" jobs.

For example, almost any practicing medial role is a tactical one - ER doctor (fix this sick person right now) or controllers for real time stuff - concert and live TV producers (make this thing look good right now), air traffic controllers (keep these planes safe right now) etc etc.

So, net net, pick you spot - tactical vs strategic or both, useful vs. valuable or both - get good at it and then may the odds always be in your favor.

I would think that anyone working in a sewer inspection van would keep the door open because it is highly likely that sewer inspection vans smell like, well, sewer.

I think they have to be long lived else they cannot make sense for performant testing. ie they are created as DB objects, using DDL, in the same way tables, views, functions etc are made.

They can certainly be created at test run time but that would slow things down a lot - you would essentially be creating a ton of objects every time you run the test which means having a setup to test if they exist or not, take them down if they do or fix them if they don't match spec ( e.g. column and data type changes etc etc )

The more I think about this, the more complicated I realize it would be to manage this dynamically:

You essentially have to build a test harness enviroment that figures out your testing elements dynamically from your data environment (with some kind of parameterization engine and data set to tell it what to look for so as to "make functors and run them" (e.g. all PKs of FKs or all columns starting with a certain prefix or all columns of a certain data type etc etc), gets the most up to date definitions of those elements from system tables and uses that data to create or update or drop functor objects ... wow, ok, this is getting complicated, I am going to stop now before I see the void.

OK, this I understand, that is a good insight - cursors are row-processing based so its gonna be slow

I think Netezza, SQL Server and Oracle are all cursor-based processing "by default" so this makes a lot of sense. I suspect that they all have bulk operation capability but can't immediately think of how I would have worked bulk processing in a way that maps to this article - maybe something like analytic functions like windowing, partitioning etc. that is definitely not row by row.

Having said that, the examples I see for actual testing in the article are DQL / DML so would be multiple row processing by default .. yes, the functor definition / creation is a DDL process but it is a "do once and reuse the definition" thing (like, the author correctly observes, a view, which is the point of functors) and the functor in use would just be DML. In which case, functors go back to looking like stored procedures...

I also understood composability as being built in for SQL - for example, in Oracle, packages allow composability of stored procedures, triggers, sequences etc allow composability of DML and views allow composability of queries and tables - which the author points out in the article.

With functors, DDL, DML, DQL, DCL, TCL would still be the only command tools available unless a new command language was invented for SQL for testing - let call that something like DTL (Data Test Language), with a whole new bunch of associated new SQL keywords, capability and functionality that are built right into the core of the DB engine that are optimized for what functors are trying to achieve.

I understand the primary premise about the difficulty with testing SQL and fully agree with it.

I do have a question though - while I understand how functors can help make the problem easier to tackle, I am not sure I fully understand how functors are different from a similar existing tool - stored procedures.

Some DB flavors:

- can take tables as arguments to stored procedures - can return tables - also offer the additional benefit of being able to run almost all flavors of SQL commands ( DDL, DML, DQL, DCL, TCL) in those stored procedures

Netezza stored procedures, for example, can do what you describe here:

https://www.ibm.com/docs/en/netezza?topic=nsg-return-result-...

As can SQL Server & Oracle (which both return cursors, which are just ordered tables):

https://learn.microsoft.com/en-us/sql/relational-databases/s...

https://docs.oracle.com/cd/B28359_01/appdev.111/b28843/tdddg...

Am I missing something fundamental here? How are functors different from stored procedures? To me, they seem to be just a sub-class / sub-type of stored procedures.

https://archive.is/zuVdE

That is essentially what has already effectively happened.

Passengers are paying the drivers directly ( and the drivers then passing on the apps share on to them - the 30% in commission and booking fee ) because when the passengers pay outside the rideshare app, the app portion becomes payable to the app.

Passengers pay outside the app because mobile money is ubiquitous in Kenya (mobile phone to mobile phone micropayments called MPESA): it is used even more frequently than cash

For this particular market, they are not charging less than the market will bear, they are charging all they can.

They have to keep taking an 'L' specifically because there is extreme efficiency in price information discoverability in a commodity market.

Explaining:

Some background info: - almost all drivers are signed up with all services [ ie i) Lyft, Uber - which are global & ii) Faras, Bolt which are international but Africa only I think ]

- riders have all apps and will price shop on every single app before booking a trip because it will be the same freaking vehicle and driver (ie literally the same service because of item above)

- ride prices are pretty expensive relative to local earnings: take for example, that first item (Minimum to and from JKIA, which is the main airport in Nairobi). It is 1000kshs which is about $8 - not a big amount in the west but is a bit of coin in Kenya - a day;. If I can get the same ride for $6, it is kind of a big deal because it means I can maybe also get a meal from the ride savings - estimates say apps takes 30% (20% commission and 10% booking fee) and this is off the top of the payment

So, the rides are a fungible commodity. It is the same ride, all you are choosing is whom to buy it from

Consider Bob looking for a ride to the airport: he looks at all 4 apps ( Uber, Lyft, Faras and Bolt), finds the cheapest one (Alice, on say the app HNewsRides) at Kshs 800 (~$6) and books that (since it is the same freaking car and driver as all drivers all use all the apps! Note that they can also sorta see - based on proximity and time to arrival for pickup - that the same ride with Alice would cost Kshs 900 on AppA, Kshs 1000 on AppB, Kshs 950 on AppD etc )

Even worse, after Bob has taken a couple of rides with Alice, and they know each other a little better, they will establish a relationship and exchange phone numbers so that Bob will just reach out to Alice directly and cut out the middle man ( apps ) because Alice will charge them the app amount less say 25% (because there is no cut for the app now). Bob gets a 10%-20% discount on the ride and Alice (the driver ) gets 20% more for the ride. This means that apps have to cut prices again to compete ad infinatum till every ride is free (or the apps are paying riders to get market share and then jack prices, which they have done )

So, the real problem is extreme information availability and a multitude of players. If there were just one or two apps, price management is easier but with 4+ players, price competition is the name of the game.

About the "it will be the same driver and vehicle" thing: this is a quirk of the Kenyan market. If an ride is showing as less than 5 mins away from you on all apps, it is likely to be a situation where it is just one specific car and driver across all apps. Nairobi has horrendous all day traffic. Really bad. Think your worst nightmare traffic and multiply by two. Two cars separated by as little as 1 mile could have as much as a 10 min difference in estimated arrival times because of traffic. So, if a vehicle says "5 mins away" in 4 different apps, you can relatively safely assume it is the same vehicle listed on across all apps.

Want to give you benefit of the doubt with regards to phrasing but tackling each of these statements as they are all factually incorrect:

1. Online prices are not the same as in store prices This depends but mostly they match ie online grocer prices in Canada are the same as in-store prices

This is because most grocers have use online prices as flyers / ads / sales pricing for stores.

Also, in Canada, because of price match policies from the grocers themselves, most grocers have to match their own online prices and, in many cases, competitor prices - this includes competitor online prices!!! including sales and flyer offers

https://blog.flipp.com/7-canadian-grocery-stores-that-price-...

Further, there is - pricing law in Canada around charging more than advertised pricing

https://competition-bureau.canada.ca/deceptive-marketing-pra...

- a pricing code of conduct: if an item is more expensive than the listed price, the consumer gets that first item for free. This means that grocers go out of their way to show the lowest correct possible price all the time everywhere.

https://competition-bureau.canada.ca/deceptive-marketing-pra...

The only exception I can think of is delivery prices where in-store pricing will not match the online pricing. But delivery is usually differentiated by completely different branding from the actual store eg Sobey's has the "Voila" brand for delivery and Metro has "metro.ca" as the delivery brand which is distinct from Metro.

2. No one, other than random people in messages forums, is alleging collusion or price fixing. No one at any university, not the government, not the media."

This is factually incorrect: grocer bread price fixing / collusion went to court and there was a $500m judgement

https://globalnews.ca/news/10642801/loblaw-bread-price-fixin...

3. The government’s investigation, which many of the conspiracy theorists site as evidence, shows a lack of competition led to 1 or 2 % increase in price over 12 years, and the vast majority of the price increases was due to things like war in Ukraine, Covid restrictions, fuel prices due to energy crisis.

Price fixing preceded all these events. In cases being investigated e.g. bread which is now resolved, the period was as far as 15 years back.

https://globalnews.ca/news/10642801/loblaw-bread-price-fixin...

THANK YOU!

Makes perfect sense now.

That is a really clever joke.

¿ Should it be "Massachusetts Bodged Transit Authority" and not "Massachusetts Bodged Transistor Authority"?

I can't help but think that I am missing a really cool inside joke of some kind here.

I get that it is an electronics project using a piece of transit authority electronic equipment so "transistor" make a ton of sense from that perspective but also get it that it is easy to go "transistor" when you mean "transit" especially if you work a lot with electronics.

Can anyone help me out with a hint ( and not an answer ) if I am indeed missing something key all together.

Either way, both article title and article content are dope.

I agree; can’t know what AI will do at this point so punditry like this is just meh.

… and this analysis generalizes all types of AIs based on characteristics of just one type of AI - LLMs - that select the “next best word “ (my layman’s understanding of what they do). With so many other types of AI out there, we will eventually definitely get new approaches to AI where the arguments presented won’t make sense

About throwing punches in the air in a tantrum - that was a funny comment. So funny that I wanted to see if someone made art of it. Found something and sharing a link here that is pretty short and to the point, sweet and cool

(I hate mystery links so some info - it’s an performance art piece called “Plastic Bag” on YouTube, 5 mins long, about 60k views, where someone throws punches in the air at a plastic bag)

https://youtu.be/-W6rn2cWs2g

Methods provide the highest leverage if you “own” the common element used across the most system components ie the lowest common denominator.

Saying it another way, don’t attack platforms, tools and channels, attack protocols since they are used across platforms, tools and channels

To this end, some examples:

Attack on

1) encryption - RSA backdoor

https://blog.cloudflare.com/how-the-nsa-may-have-put-a-backd...

2) hardware - Processor Backdoor

https://forums.whonix.org/t/expert-claims-nsa-has-backdoors-...

(this link is specifically great for this subject as it lists more than 10 different attack / compromise programs that are being run - with quite a few of them being protocol attacks - in the comments section )

3) networking - network gear firmware backdoor

https://www.cisa.gov/news-events/cybersecurity-advisories/aa...

Want to second the two parent comments to this. Small freelance / contract team of very very senior very experienced people. 3 to 4 max.

I was fortunate in that I, for the first part of my career, joined teams that were structured like this.

Some additional thoughts:

- keep things small at the start - task your team with at least two goals for the first 90 to 180 days

       i ) to define a small but critical piece of work (actually designing and coding something related to what you need to do). Cannot be part of your core platform but will need to eventually be in the platform. Picking the right piece of work here is critical.

      ii ) to define a design, roadmap and project plan for completing everything you want done with cost, staffing, tech and effort estimates

    i) if the folks and team you have put together works:

        a) as a team and 

        b) with your existing business ( can they do the work, can they work effectively with the rest of your business, is the design the come up with solid and does it give you confidence that they can tackle the real core work you need done)


   ii) if you can get a sense of what it will cost (what did the 90 day project cost and was it delivered on time and budget per the team's estimate )

   iii) if the team can put together a road map with support of the business for the broader objective in parallel to executing the piece of work chosen

   iv ) if the solution if palatable from a cost perspective ( money, people, tech, disruption ) 

   v) if the staffing model , architecture and integration proposed for the project by your new team could work (get feedback from the rest of the business about what is proposed by your new team ) 

    vi) if your business can work with this new tech team ( feedback from your existing staff about the folks doing the work and their product for the small piece of work they tackled )

- it is critical that your freelancers not just be developers: they have to be "business-goal oriented". Consider asking for references who are not developers and consider filtering your freelancer hires through their networks in LinkedIn - do they have a good mix of senior and non-senior people in their network who are NOT developers? That is a good indicator they worked effectively enough with other non-software parts of the business that the people on that side of the fence (marketing, ops, finance etc etc ) are comfortable being associated with them. Pick the areas that matter to you.

- Consider filtering for delivered results when you talk to candidates and in resumes: look for achievements / projects / work delivered rather than work done as this 'could' be a signal that the person is focused on actually 'owning' projects (not work ) and closing out on projects / goals (could also be a signal that the person did not not consider put delivered work in their resume so there is that - so, if you don't see it, just ask something like "what projects have you owned start to finish and how did you architect, design and execute on them" and interpret the response ).

- Key skills to look for in free lancers:

               - systems integration (making systems 'talk' to each other - you will have to make your existing system talk to your new system + you will eventually have to get your data off wherever it is now to your new environment and you will have to make the new system work with all the other tech systems you have now)

               - system architecture: designing software solutions

               - database architecture & design

               - project & program management 

               - lean six sigma / green belt ( means they have may have worked with ops people to optimize operations )

You will definitely find folks who have the right profile who will work with you - the key is decent (not crazy) pay, benefits and elements of stability attached (contracted duration with pay guarantees for performance, performance bonuses if possible etc etc).

- Plan on developing a bench from the freelancers so hire some mid-level junior folks to work alongside them for when the freelancers inevitably move on. You will have to hire from outside (try and get mid-level people in the industry, not senior folks, so that it is clear that your senior freelancers are the leaders / owners of work ) but try really hard to source at least a few of these folks from existing staff if possible ( people in other job functions - and are good at those jobs - who are programming inclined ) as they are a good source of how things work to integrate into the team or as new hires. They do not have to be as as senior but they have to be able to keep up. These people start as grunts for your freelancers and learn the system as it is built - they are your future tech staffing.

- Plan ahead for what WILL go wrong. I strongly strongly strongly recommend reading two books

                - The Phoenix Project - https://www.amazon.ca/dp/0988262592
                - The Unicorn Project - https://www.amazon.ca/dp/1942788762

I do not think that there is any confusion or misreading of the numbers here.

Without dealing with the specific points made in the piece, I would argue that there is gap in understanding the premise of the piece.

The article starts with numbers but it is not a analysis of quantitative measures i.e. is it not a statistical analysis.

The article is an "outside-looking-in" qualitative argument with an attempt to support those quantitative arguments with quantitative values (this is called competitive intelligence in some circles).

In other words, it should be read as an "opinion piece" with some numbers in it: the numbers are not the point, the (subjective ) opinions are the point.

I get it that numbers can be used to make a point either way (i.e. the author could use "confusion about numbers" as way to make a point while there really isn't any confusion ) but the points I would take away from the argument about numbers are:

- the fundamental premise behind putting the numbers in the piece is to make the point that they are not the same numbers that:

    i) the org has put out in the past 
    and 
    ii) other similar businesses have used and continue to use

To quote the author:

"When a company starts playing weird games with how it reports user activity, something is going very, very wrong. In general, when a company starts trying to obfuscate the true numbers about its revenue, growth, or profit, it’s a bad sign."

This is a great observation.

A clarification comment here to help explain what is going on here- re: the 'non-native' part of the comment above.

Swahili specifically is a second language to a population speaking a very very diverse set of first / primary languages.

Swahili is spoken in East Africa - Burundi, Congo, Kenya, Uganda, Somalia ( southern tip) Rwanda, Tanzania.

Kenya and Tanzania have the largest part of speakers and in Tanzania, there are over 20 'first' languages and in Kenya , there are at least 20 'first' languages as well.

Also important to note that Swahili is formally taught in primary / grade school, alongside either English or sometimes French, to a population that already speaks a different first language used by a much smaller population.

The point here is that there are many many first languages that are sources for "borrowing" into Swahili but that borrowing has to be adopted across all Swahili users who will not share that first language.

This means that only the 'easiest' / 'lowest friction changes' make it through over time into Swahili as all words also have to be accepted by speakers having other "first' aside from the ones that each word or language component was 'borrowed' from.

38-in-1 is some random storage media (USB stick, DVD. SD card, CD ) with "38" (or 45 or 2, or 99, pick a number) media files (movie, TV show, YouTube series whatever ) in various resolutions, formats, modes etc sold for next to nothing in the street.

Can be played Android-type boxes or even on phones / tablets

Essentially sneaker-net but for watchable media.

Not something you will see in much of in NA or Europe but very common in Asia and Africa where bandwidth /internet and more important, electricity, is relatively expensive.

The 90 minutes with your family comment is spot on.

in NA and Europe, this is mostly because folks don't have access to continuous internet. You are in back-country or don't have service or whatever.

In the Africa / Asia case, its because you don't have internet and / or power.

Most of the time, this media is viewed off TVs running on batteries, charged by solar, off an USB port. The electricity budget (because battery) says you get "90" mins of TV a day (not exactly 90: the power is shared between lights, charging phones, would be be more time but because electricity is limited, "TV time" is limited).

So those "90" minutes are family time, we all watch the same thing together.

Point being, in that world, Cam or SD of whatever works, no need for HD, or UHD or 4k or 8k - it is completely worthless. The screens that the content is being watched on are 720p most of the time.

Something like this (edit replaced original link with a new one that explains what is happening better)

https://www.npr.org/sections/goatsandsoda/2021/11/10/1052926...

It is exactly how all of this works

In Canada, one of the main players in the space is INTRIA

https://www.cibc.com/en/cibc-websites/intria.html

They have an office full of people processing cheques, cash etc etc. In the old world, all cheques were processed by hand but in the new world, all cheques are processed by a combination of electronic imaging and MICR: people only look at the ones where tech processes fails. Which are a lot of them.

This area of finance is called "Corporate Cash Management" - a bit of misnomer because it is not just cash and is primarily electronic these days. It is essentially about the processes that need to be in place to physically and electronically move money around.

Here are some examples of what the biggest bank in Canada offers in this space.

https://www.rbcroyalbank.com/business/paying-and-receiving/m...

The do not explicitly mention cheques because that space is really well automated these days but it is mostly done really well by technology and most banks are trying to move away to electronic payments. But if you ask for it, you will get it at specially quoted per customer rates.

Hill I am willing to die on:

Peak "$XXXXXXXX" database is when your particular flavor of DB is completely consumed into traditional RDBMSes.

Vector databases (and all other incremental or transformational improvements) are just features of regular plain traditional RDBMSes that have not been implemented in traditional RDBMSes yet.

I have seen every new DB tech subsumed by traditional databases over time as compute capability improved.

No exceptions.

The list is endless:

- object databases (e.g. blobs, JSON)

- OLAP

- in DB programming ( XX-SQL eg PL/SQL, T-SQL, ANSI-SQL)

- column-oriented data stores

- key-value

- graph databases

- No SQL

- Cloud, distributed, whatever

- statistical analysis databases

- document databases

All these used to be standalone, very expensive, specialty products but are now just one more checkbox on the Oracles/SQL-Servers/DB2s of this world.

All these have been swallowed by the borg of commercial databases without so much as a burp.

There is no winning the commercial market long term for these products. Big business buys traditional RDBMSes because they are the kitchen sink. They do EVERYTHING and they will eventually do this new hot thing, the business will just have to pay big dollars for it. Which is not a problem for big business.

There is a reason that cartoon about the Oracle org hierarchy was made (bottom right): all the company does is make product (Engineering) and protect that product. And it is very good at making good product.

https://i0.wp.com/stratechery.com/wp-content/uploads/2013/07...

On second thoughts, @moring, you are definitely on to something here!

It may be a product if one can find a way to effectively integrate content from across different platforms. Which means it has to be off any of the platforms.

Like, maybe, curated paid for lists of selected content via RSS, for my beloved, now dead but not forgotten, Google Reader

There is definitely something here.

The "patented, TM, etc" was just a joke claiming credit for the whole thing to support the "pay me" joke in the next line. It is a completely content-free line.

The idea of doing a Patreon is interesting.

The real problem is that from a technology support perspective, this is not a real tech business, it is just a feature on any of the platforms. The moment they implement some type of "Magazines" on YouTube / Facebook / Tiktok, you gotta move from Patreon to their platform because of discovery.

The product is not the tech, it is the skill in curation.

As a curator, i could care less what the platform is as long as someone pays me as much as I can get out of the system. Happy to run it on multiple platforms, on email .. whatever mix pays me the most. But I realize right up front that I will have to be paid on the platform the content is on because that is where it will be easiest to get new sign ups.