Everything is an ad these days, check any new content similar to this blogpost, YouTube videos, etc. That said, the article is brief, direct, deliver good points then wraps up with an ad.
I don't think there are any good points at all in this. On the first 5 (I gave up caring to type up more):
> 1. This won’t get new users
App Stores are still a discovery mechanism and it's a pain teaching users how to add them to their home screen vs. just linking to an App Store entry.
> 3. It defeats the whole purpose
There's times to take on the world and times to join it, and the current trend is to put them in the App Store. I don't know how many companies starting out can afford to wait for the world to change on this.
> 4. PWAs don’t belong there
Incredibly subjective.
> 5. App stores aren’t more convenient
...huh? Users are already familiar with the flow to open an app store and search for a company. Users are generally not familiar with adding a bookmark of a PWA to their home screens.
I visited SF recently and they smashed by trunk, found nothing and left me with the repair service from the rental company, it was a Friday morning at a park.
This is a silly statement. It’s victim blaming and not actionable. Don’t park a rental in the city? Ok where am I supposed to park? Or should I not drive here to start with. But then I’m walking in San Francisco and I hear that’s not safe either. Or perhaps not come here at all?
Don’t be a photographer in San Francisco. Don’t go to a public park. Don’t drive home from a photo shoot in San Fran because thieves will follow you and steal from you.
Stop blaming the victim for doing normal life things.
There’s plenty of blame and plenty of heads to put it on before you need to stoop to that level.
You're right. The first sentence reads as advising what to do. I should have skipped it and gone just for the statement of fact in the second sentence.
Also, the first sentence is not inclusive enough, as they target rentals even when not parked. Cars have had windows smashed and bags stolen while occupied and sitting at a red light.
When I had to visit for work few months back they specifically said I was not allowed to park in SF. So it seems that if the car is damaged while there the rental company is going to make you pay, even if you're the victim of the crime.
Nobody mentions User Experience. SourceForge was terrible, Google Code also, Gitlab has an acceptable UX. Github kills it in most fronts.
What prevents Github Copilot from expanding to FOSS that is not hosted by them in the future? Just how Google indexes and caches the whole internet, what prevents this thing from going to public gitea of FOSS projects and scraping to train their model!?
When you join GitHub you accept their ToS which among many things gives them the rights to use your code for stuff like Copilot. Theoretically (although I'm not sure of this is the case, looks like no one does right now) Microsoft would have to change the way they handle code licenses in their training set if they were to use code hosted elsewhere, giving attribution to code from MIT licenses and not using AGPL code at all.
> When you join GitHub you accept their ToS which among many things gives them the rights to use your code for stuff like Copilot.
I get so many "our terms of service changed" emails and they link to a 30+ page document with not even a diff of what changed. I vaguely remember GitHub sending one out maybe in December 2019 but it linked directly to https://docs.github.com/en/site-policy/github-terms/github-t... and didn't even hint what was different so the only way you'd be able to know what changed is by re-reading every single word.
This is one of those things where you technically agree by continuing to use their service but no one can realistically be expected to read a 30+ page document for the 20 services they do every time a provider updates their terms without a diff. You'd be reading one of these at least once a week.
The email I got from GitHub also didn't include "pilot" anywhere in the body of the email and neither do their current terms of service, so now you need to be able to decipher whatever wording they use to translate back to "co-pilot". After all that I also have lots of emails from noreply@github.com and searching my inbox for emails from that with "terms" in the subject doesn't show anything related to co-pilot.
I'm not a lawyer but I can't imagine if you agree to the terms today but 3 months from now new terms have been added -- you don't passively start accepting those terms without an explicit action to say you do after you've been notified of the changes.
I used TabNine for years, if I recall correctly it was developed by a Waterloo (Ontario - Canada) student and bought by an Israeli company.
Once they changed their EULA my security aware company was like can't use that anymore.
I provided that feedback to them but I guess I was the only one raising eyebrows.
My suggestion is just lower your price to match Copilot, so it's easy on the user deciding between both of you, I am for one sold on how useful Copilot is.
Would you be willing to share your concerns about the EULA? The pricing question is something we are currently discussing as you can imagine. It is surprising that our EULA was a problem but GitHub's was ok given they collect your information for training.
Heroku is a one of kind platform, many tried to replicate, none have come close, the ability to setup a whole app with a few clicks on dynos and add-ons is great. The price was always salty $50/month for 1gb RAM shared CPU, and in the few past years no newly released features comes to mind. As a customer I have no idea what this security issue impact, the communication has been poor as this post does not clarify much, you have to click a status post link to see a feed of what's going on.
Their docs are really copy paste for 99.9% applications. Whoever in that company made the decision to invest in docs was right on the money. It made switching to them a much easier choice. https://render.com
Update: Migrating the simplest possible Rails app from free-tier to free-tier didn't work on Render (deploys fail, no logs to be found), so I'm bailing out to try Fly.
To any render people reading this, it appears to have been an issue with the migration plugin and the Heroku-18 stack. Manually deploying the app worked fine.
Thanks for the heads up and good to hear you were able to deploy the app manually. We might deprecate the migrator because it's hard to keep up with all the Heroku stack and buildpack configs and because manual migrations are relatively straightforward.
> Whoever in that company made the decision to invest in docs was right on the money.
Also the reason Django has always been so approachable (particularly in the early days, as it is orders of magnitude more complex now) and therefore popular
Older still, IMHO also why mIRC scripting was so much fun despite its shortcomings. The help file had literally everything you could want to learn about the language and it almost begged to be read. It's how I got into coding
I hadn't heard of Render prior to this incident, but now I see it recommended in almost every related thread. Of course, Heroku's free tier had always worked well enough for my hobby apps, so I had no reason to search for alternatives. Looking forward to giving Render a try.
I would love to do buy gstreamer course to learn more, I am finding the documentation hard to navigate on the macOS platform, it seems very linux friendly. Keeping an eye for study materials.
The author started the topic really well, be defining a separation between Javascript/Typescript.
I find the examples that followed to be a demonstration without purpose.
After reading them I don't know when to use them, he mentions "type gymnastics" at the end and I find that most of the examples are demonstrations of type gymnastics.
I work on a large Typescript codebase and rarely I need to do abstract typing in order to get something done, Typescript can be used in a very direct and objetive manner and it's usually the route I prefer.
The key takeaway is that they built constraints on the wrong place (prospects vs clients), so they are revisiting their pricing and constraints. It's a good example of listen to your customers.
The author does not suggest how to get stuff done, for that reason I think the title is clickbait. The issues the author has with Scrum are relatable, on top of that there is also rituals, someone recently switch teams and they were happy that we had 1 ritual and on average ~2h of meetings a week, compared to 8h of meetings a week on the other team: planning, retro, daily stand up, pre-planning, grooming, scoping, etc.
If you read to the end the author links to their second article suggesting Kanban instead. I concur with this suggestion in general. This talk is an entertaining classic intro into it: https://youtu.be/CKWvmiY7f_g
I used fossil in the past for my personal projects, it worked great but it had too many features for a solo developer, getting others on board of using it is hard, given git is mainstream.
