Check on AI startups that were VC funded 18-24 months ago. Likely a spectacular graveyard of colorful gradient B2B SaaS garbage. (I will admit the “AI look” is a lot cooler than the “Web3 NFT” look.)
I assume this is using some kind of amazon pricing API under the hood. Does anyone know how to get access to that kind of API without already being a successful affiliate?
I'm a bit surprised Amazon allowed this page to do affiliate marketing like this. I had a similar page but much more generalized to laptops and they told me my site had to have some other content: it couldn't just exist to promote the amazon products. If they've changed their stance on this then great!
Chances are he had a blog or something with content/pages and got approved. Then just re-used the codes/keys for the affiliate links on this new site. Once you start making money Amazon doesn't care.
Source: Me. I had a comparison tool for products with similar layout to this. They originally denied it citing 'lack of content'. Made a 2nd website with some blogs/reviews, it was approved. Re-used the code/api for the comparison tool and closed the other website. They haven't complained in 12 years.
This has "content". The filters and columns are different to those offered by Amazon's own search experience (the $/TB, for example). Did your laptop selection site just replicate the data from Amazon, or did it try and do something novel?
"Content" is not alway descriptions, reviews and the like. It can be aggregation, statistical and calculated.
>Did your laptop selection site just replicate the data from Amazon, or did it try and do something novel?
I thought it was novel. It was basically a guided questionnaire that asked you about your needs and price point and then spit out a laptop recommendation at the end
> The following marketplaces have threatened or suspended our accounts and are unlikely to return to diskprices.com without clear policy changes from Amazon: amazon.jp, amazon.nl, amazon.it, amazon.sg.
That wasn't the issue I had at the time. I had the required disclaimers but they still rejected me because the sole purpose of my site was to sell their products.
I working in XP for a bit and the constant pair programming aspect was simply too fatiguing for me. I enjoy pairing every now and then on certain problems, but the constant presence of another person left me utterly drained at the end of every day.
I know some people really work well when pair programming, but I find that I either slip into Student Mode or Teacher Mode when I try it. Either the other person knows the environment we're working in (architecture, codebase, etc) a lot better than I do, and I'm using the session to gather as much information as I can, or I know the environment better and so I'm explaining why I'm doing things.
If the other person and I are on par with the environment then we're more likely to have a discussion about what we're wanting to achieve and how best to go about it, but then one of us will go away and knock out a first cut for the other person to review.
I do wonder what differs between groups of people who can actually do pair programming and those that (like me) that can't.
I think slipping into student mode or teacher mode is a fantastic reason to pair: it's full time training. You quickly will all rise to the skill level of the best parts of every engineer on the team. Otherwise training is rare and slow.
My mode is either driving and listening to advice or watching and trying to spot things the driver missed.
Occasionally I do side-work if Im not driving - e.g. look something up, message devops, a very small PR etc. so the driver can maintain focus.
I find it to be much more effective that working alone simply because so much stuff that would take me 20 minutes to to go down a rabbit hole ends up being caught by an extra pair of eyes in 4 seconds.
Yup, my major beef with XP back in the day was in its arrogance: This is the way to do things, and if you don't do it entirely this way, you're not extreme programming! (that was literally in the manifesto)
But the article highlights the good points of agile, and I agree with them:
- Iterative development (smaller steps with faster feedback)
- Unit tests (and building with unit tests in mind)
- Code Refactoring (which you can do confidently when you have unit tests)
The rest of XP/Agile is not necessary, and in some cases even detrimental. YMMV
> if you don't do it entirely this way, you're not extreme programming
But isn't this... OK? Extreme programming is probably defined as a certain set of practices, and if you are doing a subset of that, you are doing something else. This doesn't make you into a bad or a lazy person; it just means that your process is something other than extreme programming.
It's the same with scrum. It is extremely common for people to pick some practices from the scrum framework, skip others, and still claim that they are doing scrum. It gets very confusing when people do this.
The problem is that these kinds of things become shackles for the mind, denying the agency and mental suppleness required to navigate a changing and chaotic world for which we can never achieve perfect knowledge (or even anything remotely close to it).
There is no such thing as a perfect set of rules or practices - only things that are useful in certain contexts. It is the practitioner's task to decide which principles apply, and to what degree.
Saying "You're not doing [brand new popular thing] unless you do it this exact way" is a trap laid for neophytes who lack the experience to discern that this is just arrogant bullshit, denying them the exercise of their own brain to judge what applies where (and learn from their mistakes).
Scrums biggest problem has always been management interpretation of sprints as deadlines (commitments) and not estimates (forecasts).
The former eventually leads teams to lowball everything to make sure they always complete everything at the expense of trying to accomplish more. Which will then lead the company to wonder why everything is so slow.
Getting people at the top to understand that challenge is the hard part.
Scrum, XP and/or Agile are not going to save you if the guy leading the project decides the hardware and firmware have to be completely re-done for no good reason other than his own opinion, lack of experience and ego mixed in with a bit of "not invented here syndrome", "if it ain't broken fix it anyway" and "make it complex not simple stupid" (recent random example).
My point being: other aspects of companies and teams are far more important than the latest fashionable project management methodologies/frameworks/philosophies.
The critical piece to any framework is how work is prioritized. If it’s by 1 guy, you will have the problems you describe.
If you have an approach that forces the people doing prioritizing to weigh Return on Investment (benefit or value / estimated time) to largely guide the priorities, busywork with little benefit like you describe won’t be prioritized.
Often the people at the top understand. However what most developers fail to understand is the guy at the top really needs accurate estimates. the more accurate the estimate the better he can do their job. Thus they are constantly loohing for a magic bullet that gives them that. it doesm't need to be perfect, but the closer the better.
It's not that they need accurate estimates is that often sales people want to share those estimates externally, so anything that takes longer due to unexpected complexity becomes an accountability issue.
There is a balance there. sometimes you need to sell on the next version's features to get enough now to develob that. Not everyone gets unlimited venture capital - and it isn't always a good idea to take it if you can.
Accountability is everywhere, but software managers are always looking for the silver bullet that would let them have a stellar reputation of being on time.
> Scrum practitioners/coaches always seemed to have this idea that if Scrum wasnt working then you werent doing it properly.
And if people mean different things by the word scrum, it is rather hard to tell whether they are doing it properly :-)
Scrum is pretty difficult to do properly (the famous "easy to understand, but difficult to master" formula; although I would argue that it isn't that easy to understand either, at least not something that someone unfamiliar with it can understand in a day or two). It requires certain changes within the organization, which few organizations are willing to adopt.
I find this to be a problem with agile, but not so much with Scrum. It's quite proscriptive and there is a set of quite specific rules and processes you can follow.
> I find this to be a problem with agile, but not so much with Scrum.
I am seeing problems left and right. Mostly because people often copy the activities (they would often even call them rituals or ceremonies, as if to make it even more obvious that they are treating them as mysterious quasi-religious practices) without understanding what they are intended to achieve.
For example:
- Lots of daily scrums in which people go around the circle saying what they did yesterday and what they are going to do today. No sense of a common sprint goal, and no indication of collaboration in reaching it.
- Lots of sprint reviews that are just demos
- Lots of sprints without goals, that are just timeboxes to finish a certain number of tickets/stories
- Lots of teams that remain hierarchical, and instead of a real product owner have some kind of a middle manager (who might also assume scrum master responsibility, because he is manager)
- Lots of teams focusing on story points, velocity, and estimation
- Lots of teams that don't adapt previously formed plans to the emerging reality
>Lots of daily scrums in which people go around the circle saying what they did yesterday and what they are going to do today. No sense of a common sprint goal, and no indication of collaboration in reaching it.
I remember reading the scrum manual but I don't remember it saying anything about it being necessary to show esprit to corps and a "collaborative spirit" during standup.
It did say how to conduct a standup ceremony though...
>Lots of teams focusing on story points, velocity, and estimation
Code refactoring with unit tests is fine when it is within the unit test units, but when it crosses unit boundaries the tests often must be re-written, doubling the effort required.
I actually loved it. I had never learned so much or shipped so quickly and reliably.
And then I moved teams... And realised it's all about the people and culture around you.
I probably wouldn't sign up for it again when joining a new company, because at its worst it's absolute torture, but I still believe that at its best there's nothing like it.
You both can be right. It can be the best way for you, and it can also be utterly exhausting for them.
Personally, I'm not willing to get rid of _all_ my comfort zone to get something out the door more efficiently, where shareholders and C-levels get rich off my labor, and if I'm very lucky, I get to keep doing that.
If I had to pair-program, I'd probably call in sick. And if this was a repeated demand, I'd eventually just quit.
To me, this is one of the worst ways to work. I very much prefer to communicate in writing, and at prearranged times. To me, the idea that there's another person working with me on the same problem at the same time is as absurd as having another person cooking in the same kitchen with me, or painting on the same canvas as me. Whatever result I can produce on my own, it will be ten times worse if I had to do it with someone else working on the same problem with me.
I went through a period of a couple of months where I pair-programmed almost every day, and it was probably the most productive time of my career. My partner was very junior, and new to the project, and the process of explaining things to him definitely helped avoid some of my blind spots. He had several good insights and ideas, too, coming in with fresh eyes.
It was high-energy, though, and an extended period might well have been fatiguing.
first, there's a definitely a stamina to it - I worked in an XP team for best part of 3 years and have at other jobs done a lot of full-time pairing (sometimes months at a time).
Second, there's a chemistry element. When there's good chemistry it can be quite effortless and the chemistry can grow - as you start to develop an intuition for how the other person thinks there's less communication and mental jostling.
I've had remote pairing sessions that have felt almost as fun as online gaming.
>The FAA said the inspections will take between four and eight hours per plane.
Seems reasonable. I was wondering if a single event should really be enough to "ground" all similar planes, but seems like they just want to do a quick inspection.
A single explosive decompression event, comprising the spontaneous loss of an assembly the size of an entire exit door, two months off the factory floor?
I should certainly hope they’d take a gander at the others before I’d sit next to one.
Especially with the memory of the last time they chose to keep flying 737 MAXes instead of fixing the defect in the rest of the fleet, at the cost of 157 lives, not even 5 years ago.
Let's also consider just how much worse this situation could have been. The door panel blew out next to the one seat that happened to be unoccupied, and it happened at 16,000 ft instead of 26,000 ft.
And even so, sucked the shirt right off the boy in the middle seat! I shudder to imagine how things would have gone 20 minutes further in to the flight.
No it's not. Crews are trained for decompression events and they've happened at higher altitudes than 26,000 feet before with no airframe loss at all (for example, the Southwest 737-700 where a fan blade ruptured the window happened at 33,000 feet). It may likely have been a fatal incident but definitely not likely a crash.
If Boeing is necessary for national defence and no longer knows how to build aircraft, drastic action is needed by the US government on a very short timeframe to get their shit together. War is a thing.
In the meantime it's hard to disagree with the sentiment elsewhere in this thread that flying with airbus seems a better idea.
Yeah especially given the public trust the FAA needs to rebuild after it came out how Boeing got the 737 certified in the first place. It’s an unmitigated shit show top to bottom.
You mean 737MAX. The 737 and 737NG have been around for decades (almost 60 years for the 737, almost 30 for the 737NG). IIRC the 737NG has a reasonable case for being the safest airliner ever built. There are some designs that have no fatalities, but they also have very low production numbers to go with it.
> safest airliner ever built ... very low production numbers
If one model has 5 million flight hours and zero crashes, and another model has 500 million flight hours and 50 crashes, is it possible to say which model is safer?
The point in the outer comment was that the 737NG has both many flight hours and ... if I skimmed Wikipedia correctly, only 1 mechanically-attributed fatality.
For reference, the most-produced passenger/cargo aircraft:
16K Douglas DC-3 (1935)
11K Boeing 737 family:
1K Original (1967)
2K Classic (1984)
7K NG (1998)
1K MAX (2016)
11K Airbus A320 family (1988)
Different sources give oddly different numbers (more than I would expect for ordered vs built vs delivered; I didn't investigate deeply), but nothing else is above 2K. Note that plenty of small or military planes beat these numbers.
I’ll take the one with 50 crashes any time. That’s 50 times something went catastrophically wrong and 50 times measures were taken to fix the underlying problems.
A brand new plane will undoubtedly have brand new problems.
I think this is the wrong take, for the following reasons:
- There is no reason to assume that the learnings from the 50 crashes weren't also applied to the newer model. In fact you'd expect that they all were.
- Faults in a new design are likely to be front-loaded, meaning most of the crashes would have happened earlier than later. Therefore the new model seems to be a much safer design if it flew 10% of the miles without even 10% of the crashes (actually 0%).
The point is that commercial aviation is so extraordinarily safe, that mechanical failures that result in fatalities are too rare to determine if a model with 5 million flight hours is more or less safe than another model with 500 million flight hours.
Zero fatalities does not mean the aircraft is statistically safer unless it has an order of magnitude more flight hours.
I'm not sure if I agree or not, but my thinking were that it wouldn't reach great safety by upgrades until long after it became too expensive for Boeing and would instead be replaced with a new model.
Of course it should. This is a manufacturing defect that could easily have sucked someone out the plane or dropped debris on someone’s head. Should it happen during cruise over water the consequences could be much worse.
OP's solution isn't remote code execution though. It's all in-browser, which is why it's pretty cool. Assuming you're only running code that the client themselves are providing, you're in pretty good shape from a security perspective.
