bdg

Just some experiences I've had putting large PHP frameworks into strange spaces:

1. Most PHP frameworks are designed to have all state destroyed at the end of a request. I was trying to integrate a commercial ecommerce framework with something like Road Runner and another one that I forget the name of. The framework had a DI system which provides each module with its own private instance of all injected instances, so having a "worker" that doesn't "boot" everything each request sounded like a good idea (boot was expensive, and a lot of logic was storing module-specific state in module-private instances). I hit a few barriers inside the framework, but actually a lot of them were due to dependencies on PHP global state following state-of-the-art conventions and best practices. It lead to spooky side-effects like cache from one page view loading into the next, and worse. Getting frameworks to run in a loop in PHP can often lead to sharing state in code that was designed in a way that state is assumed to be destroyed soon.

2. PHP depends on lots of unexpected things. If you're deep into language internals already you probably know this however. I was putting symfony2 into a PHP Unikernel a long time ago, and it drove me a bit crazy because everything in the file system, SAPI, locales, etc... it was all missing bridges to something it expected the OS to provide. I ended up making an immutable FS with Nginx and PHP all static linked to each other, but it was really just enough for a POC, a real production ready env would have been a lot more effort. The point is, PHP has a lot of unexpected "hooks" into environments it has grown up around that might be well hidden.

Anyway, really cool project and I like the concept of using a SAPI, I think it has big potential.

With the high churn of devices and increasing privacy intrusion, there's probably a small market for burner phones that will re-emerge just for apps in the next years.

I think this had something to do with the base ethos of North American style crime & punishment.

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

Feb 7, 2022

> Biden: “If Russia invades -- that means tanks or troops crossing the border of Ukraine, again, then there will be no longer a Nord Stream 2,”

> Journalist: “But how will you do that exactly, since the project and control of the project is within Germany’s control?”

> Biden: “We will, I promise you, we’ll be able to do it,” Biden replied.

I don't want to play conspiracy guy, but the statement stuck in my mind since he said it.

Hey, did anyone tell you that being a rude prick on the internet is an irritating hobby?

It's like you showed up just to dump on the author. You added no value here.

You fail to articulate why it was hard for you to read. You failed to articulate what might have been better. You failed to have a basic level of compassion and human decency in a way where you could even make a base-level attempt at wording your post as anything other than a snarky attack.

I'm personally sick and exhausted of commenters who behave like this. The people who contribute nothing but put in the extra effort to show up in comment sections to dump on people who are trying their best to share or build something.

But what's the issue with making a post and discussing how a product one made solves an issue? GPT-3 and DALL-E are both products with a pay-per-play model. So is AWS and S3. We talk about those things all the time with no scrutiny or suspicion.

It's because you're the CEO of ChiselStrike.

I don't get it but there's a good chunk of people who are ready to jump on anything that looks even slightly comercial by even one single aspect. I've been told my personal blog was AI generated blog spam once in the past when I had literally nothing to sell. I also don't understand the fundamental issue with having a commercial involvement as long as you aren't trying to BS people or shove advertising down their throats.

Strong agree. It reminds me a bit of the format of interview that unskilled or inexperienced hiring managers come up with:

  - "How big was your team at your last company?"
  - "What languages do you use at your last company?"
  - "Do you prefer to use for..in loops or [].for() notation?"

And using the surface answer as the way to make a decision. Being able to navigate a topic from broad-to-specific is a specific skill that is rarely taught and are very lucky if they manage to stumble on to it after enough experience and self-reflection.

A lot of the comments in here are reacting to the large list of questions being very off-putting. There's a deeper issue here that we still don't have a good answer for: it is incredibly hard to tell what a company is like until you start working there, and asking questions either leads to very surface-level answers or just flat out catfishing candidates. Companies being transparent and detailed about how they operate is the exception.

The company gets to spend 3+ hours finding out information about a candidate, but the candidate has little option to discover company culture for themselves. They can snoop around on LinkedIn but this doesn't answer much about culture unless there is someone who is prolifically producing content inside the company. There's glassdoor which might answer part of it but generally the reviews there are extremely shallow and biased by the skills, mindset, and treatment of whoever wrote the review.

So what's the answer? I think "ask targeted questions" is fine as long as it is not "ask 100 general questions". I haven't seen a single article on the meta of how to pick what questions to ask or how to get past shallow answers. I also think the entire industry is performing pretty terrible in this space and we don't have a good answer for how to handle it that is common or even well-known. This leads to lost candidates or (intentionally or unintentionally) catfished candidates who will leave after joining.

How would you solve it with very little computing resources? I've yet to see any reasonable solution.

Dependency solvers that obey semver are a really hard problem that have very unintuitive challenges. I think a very large number of people who use them will not have spent a lot of time to think about the issues in detail, just their experiences as a user of them. NPM has less complaints than composer for example, but node_modules has an interesting way out of the problem by making dependencies into a hierarchy but this brings a new bunch of challenges elsewhere (in the runtime, any object transiting between a mutual package which has two different package versions of the same package name in the lineage will be have "weird" behaviour).

  Your Project --depends-on-> Foo@1.2.3 --depends-on-> SomeLib@1.2.3
  Your Project --depends-on-> Bar@4.0.1 --depends-on-> SomeLib@4.5.6

If Your Project touches SomeLib from Bar and passes it into Foo things go sideways. It's easy to state that this violates best practices but it is a reality of how the runtime works. This category of issue is removed in PHP/Python by the package manager (not the language). The trade-off is the large computation that checks for conflicts in SomeLib.

They recently updated the algo to handle better performance but I don't know what it is now. Top-of-mind I think it was a 30% wall-time improvement.

The history of dpkg is really interesting, it has its roots in a a biologist trying to avoid ripping his hair out with dependencies so he wrote "StopAlop" (http://www.verycomputer.com/195_d4343843af185e14_1.htm). A few months after he posted it others took on the task of porting it to a more robust shell script which was eventually re-written into C, and slowly evolving into what we have today.

What's more interesting is that a lot of package managers for programming language package managers use (or used) the fundamental concepts in dpkg. For example, for a long long time Composer (the thing that saved PHP from death) was a re-implementation of some parts of dpkg with a language-specific world view. I don't know for sure about others but I think this is also true for NPM, pip and ruby gems.

Something else that I think about a lot: the industry spends a lot of CPU cycles to compute the suitable dependencies, but there are several alternative ways to solve dependencies. But those alternatives don't generate interest because the StopAlop lineage is so built in to how we work on software it almost goes unnoticed as a natural law of the world like gravity, so there's no prompt to directly challenge it.

> the unspoken implication is that employees can't be trusted. That is probably true for many employees, but not all

There's an interesting reality here that managers hire and keep people in a state where they can't trust their direct reports. The manager is just as untrustworthy.

As a kid I had a great book with lots of science experiments in it called "Science Is" (Author: Susan V. Bosak)

It had an entire section on airplanes but there was one that absolutely destroyed my intuition about flight and to this day confuses adults whenever I get the chance to make it (something like a team building event where we need to make paper airplanes).

It's literally two hoops of paper and a stick. Here's a page I found with the design.

https://www.exploratorium.edu/science_explorer/hoopster.html

One of the interesting points is that this is about 50 years before Fourier claimed FT was possible.

I would love to have the CAD files to recreate something like this.

By the way, the questions from the research are available in this easier-to-digest tool: https://docs.google.com/document/d/19qSFKDz9AuR_nlsXQjZD-gpt...

That's fantastic, please send me an email, brian@statagroup.com .

I'm going through this challenge right now too. In my case I'm creating content to help improve the skills of Engineering Managers and I'm really stubborn about a few things like needing to ship the entire most-loveable-product (as I imagine it from my armchair) and not the minimum-viable-product (as proven by real customers).

I am a bit lucky to have some product skills to identify the mental biases and traps that I fall into, and some friends help pull me back too. Other commenters have pointed out some of those problems:

- Look for positive signal from real flesh-and-blood customers who will give you real money. I printed out my content and had lunch with former colleagues to pick their brains on the topic. I kept doing small tests to check one single area of the final concept.

- Downscale. Downscale. Downscale. You might conjure up 100s of reasons why you can't dare approach the market with a faint shadow of your final vision but you need to do it to test that you aren't making a huge mistake. They will not love it. You will not make money. But you also will not waste time doubling down on a fantasy. Gumroad is good for this but I'm doing it on Shopify just by reducing my product to 10% of the content and printing 1% of the order quantity I need to make a real profit (so I will lose a few hundred, but I will validate if I should spend a few thousand)

- Figure out how to market. You want to do this because this is a form of your "sales funnel" and how you will actually identify who you want to attract, how to do it, where to go, etc. I'm highly unskilled in this topic but I'm using a book called "The 1‑Page Marketing Plan" which helped me structure a lot of things that I had observed in life and start to build a proper plan in steps that was logical and connected. It's not the best book ever, but it is good enough to get oriented and do something logical.

Just curious, what do you use the resultant XML for? Analysis? Rewriting code?

What would it have helped with?

>I've found myself manually writing code for finding things in python's AST but a tool like this would be much more succinct

Wow, I also am writing a tool for finding things in the Python AST: https://github.com/Incognito/python-architecture-linter

It does other things too, but one of the key features is reading the AST. It's a bit of a prototype but if you want to jam together on a project I'd be open to it.

Yes, and sometimes shitty jobs are behind great people. Candidates get catfished in interviews all the time.

Yes, our industry has a lot of inexperienced managers and interviewers who don't know what to evaluate or how to clarify the goal for a candidate.

I think this is a different challenge related to the "background" hidden context: training interviewers. I think the "foreground" discussion point ("please make me a car") is way less relevant than the skill of an interviewer.

For about a year I tried this with every candidate: literally tell them what I am looking for in the interview and what is on my scorecard. Nobody asked any questions even once.

> It takes a brave interview candidate to say "the best solution depends on the exact nature of the problem - and your problem doesn't make any sense so there's no valid solution".

I got that a few times and it's a good sign I have a senior candidate.

The real-world use case is simple when you imagine that I want to get a JSON payload describing different car configurations, possibly for a "car configurator" on a sales website, or perhaps for a videogame where there are different cars with different attributes at random. Once I go from "make a car" to "give me some json" everyone started to see it's as a less fictitious problem.

I actually like to ask people in interviews to model a car and car factory because I want to see right away if they go deep into the nonsense of extending everything, or if they can use composition, or get away with something focused on maintainable code that meets requirements.

I've seen it all. Prius extends Car extends vehicle extends motor extends ...

Right within the first five minutes of the interview.

But I also think these old "a bike extends a " tutorials were the most frustrating thing in the world and made no sense to me when I was trying to learn OOP in the first place. From my memory, I recall all the examples I could find were absolutely nonsense but blogs were full of posts with lots of non-real-world about connecting web requests things to a DB code and lots of "yeah it's just like a person is-a mammal which is-an animal which...".

It wasn't until I wrote some c++ and looked at how it worked in the heap and stack before I started to understand it better. Then later I learnt about SOLID and discovered that you almost never really want to use extension in practice (at least in the problems I worked on), except for things like interfaces in places you expect (and plan to have, and even better if you already do have) a reason for variations in sub-types that have the same contract, or need to cross system boundaries.

I almost always want to use composition. I will use extensions but this should be really specifically be selected for a few key points.

Of course, it's here:

Build people; not software

Build context; not documents

Build value; not lines of code

Fix root causes; not symptoms

Really cool link, I will need to try DACI. It reminds me a bit of RAPID ( https://www.bain.com/insights/rapid-tool-to-clarify-decision... ) but possibly more light-weight.

I also have this experience and I've gone as far as to build this understanding into how I improve teams.

I wrote myself a short alternative to the agile manifesto which includes the phrase "Build context; not documents". The documents are relatively worthless if you cannot get context across, so I also prefer these big sessions where everyone is in the room.

But I take it a step further. Instead of just having meetings where we discuss I start to drive in structure and formats. The team knows by the 3rd iteration what the process will look like: we do some customer empathy discussions, identify requirements, break down into something that looks a bit like a C4 architecture, and then break down into task dependencies. In each of those sessions I create the structure and coach the team in the workshop but also 1:1s to start using structured processes and less ad-hoc ways to communicate. For example, if we enter a requirements conversation about the customer and someone talks about MongoDB I tell them we need to defer the DB conversation. If we open a Miro board I enforce that we all use the same types of diagrams to discuss the same thing at the same level of abstraction (increase team discipline).

After the team learns the supporting structure for the process, the process takes less time each round. Lots of waste generated by confusion or off-topic discussions or non-critical points are removed or deferred to the right time. I did this with multiple teams in the same company, usually the first round takes 1-2 months, but the 2nd round takes 1 month, the 3rd can take 2 weeks, by the 4th round they can do everything without me (on average). They end up creating documents, but the difference is: now they have context, and they are "fully literate in a new language" which lets them move faster.

If you're interested, I wrote a bit about why I dislike the blind application of templates and process frameworks without context or "deep thinking" a few weeks ago: https://statagroup.com/profiles/brian-graham/request-for-fas...

The shared context in the brains of people working is all that matters when you want to drive outcomes.

Context is king.