We have review environments so there is an easy way to have a fairly persistent config to QA features, but our environment that's named staging is more of a historical artifact. It's basically the same as a review environment because we recognize that after testing that the feature works as intended, it's going out and, we may be surprised by real production use. Our test suite, which is kicked off after you hit the merge button takes about 10-15 minutes and build/deploy to Amazon ECS is 8 to 10 minutes so there is pretty quick feedback. We also use feature flags when possible, but most deploys are very granular and we generally don't worry if something passes our test suite which is currently about 6k tests. Once we decided that merge to main get deployed automatically our staging environment became just another environment, our velocity increased, security patches are deployed almost immediately and we mostly don't worry about launches.
Events are foundational to JS, we've had them since the beginning and they're not broken. You don't need any nonsense to use them. They're also completely unrelated to promises in my opinion, so I'm not even sure what the ecosystem would look like if you tried to replace Events with promises.
Consensus is one thing, taking action on that consensus is another. We have failed to significantly increase the supply of housing so the cost of the existing housing has been on an unending march upwards. The solutions people are willing to implement are half measures and avoid the supply-demand causes of this problem.
Every city in the state of California for many decades has failed to build enough housing to address the ever increasing demand for it and as a result people are losing housing. Every time rent increases significantly, homelessness increases significantly. The cost of housing in California cities and the Bay Area in particular has never decreased or even stabilized because we treat housing as an investment, keep it scarce through a number of local and statewide impediments to building, and expect outrageous returns on existing housing over time.
It's a common misconception that people experiencing homelessness are all junkies, but it's not true. A large number of homeless people are working poor. Estimates vary from 25% all the way up to 60%. If you sleep in your car because you're priced out of an apartment and you have a job, you're still homeless. Not everyone that's homeless has a needle in their arm, shouting at traffic on the street.
You're very incorrect. There are a huge number of people that are homeless that have full time jobs. There are a huge number of homeless people that don't use drugs. The problems they have are many and nuanced, trying to blame it on a single thing is a gross oversimplification of a complex problem. The solution to homelessness is housing first.
> In my opinion, I lack evidence, the money should be targeting preventing people from ever getting homeless in the first place. The intervention needs to happens earlier because once a person is homeless the problems that contributed to their situation become insurmountable.
The city of SF does this already. There are nav centers and they triage cases for people that are on the brink of becoming homeless. The first step is prevention, but in an area that has booming rents, booming homelessness is never far behind. If you grew up in SF and you become homeless you're likely going to return to the place you know even if you don't have a place to live. The complete inability of SF to build housing at any income level is the biggest driver.
This is great. I never understood why we allow people who don't own the land dictating the terms of the housing that gets built when we need more of every kind of housing in California. The fetishization of single story mid-century construction is especially confusing. Land is expensive, build up, not out.
When you're using an ecosystem like Rails, Redis is assumed to be a basic part of the stack so you don't really give it a second thought. Between ActiveJob/Sidekiq and ActionCable leaving out Redis leaves some large pieces of the framework on the table.
Two weeks ago I had an update rejected because we decided to remove Login with Facebook from our app. The plugin that provides that support to Cordova is a dependency nightmare and not many people used it anyways so we removed it during a bugfix and dependency update. We got flagged for only supporting Google as a 3rd party login and basically forced to implement Apple ID sign in to release our fixes. Since adding support we've been further held up from releases because we require an existing account for Apple ID sign in to work and they rejected us for not allowing the QA account to sign in, while completely disregarding the use of the QA user account and password that we've always provided for the review process.
tl;dr Because of the broken App Store review process we've just removed 3rd party auth support from our app, which is a shame because it's a really slick sign in experience, but we don't want to deal with bugfix releases being held up in review.
You can absolutely trip from a transdermal dose. The kind of prying and jimmying required to disassemble a vintage synth unit could easily spread any film or sludge all over a significant part of a person's hands without gloves. Then all it takes is a bit of sweat or touching your face and you'll be unintentionally tripping.
Antifa is not a single organized group, it's anyone who is anti-fascist. So there is no 'real' antifa groups. The police don't have a very good track record releasing truthful information regarding these events, so why not chill out before drawing your own outrageous conclusions.
I disagree with naming conventions for branches. Just give it a name, I like to have have a bit of fun sometimes. For example: 'org-mode', 'more-org-mode' and 'org-mode-3-still-org-moding' are 3 real branches I recently shipped. All the naming convention does is make another pointless argument. As long as the name is more descriptive than 'my-branch' I'm fine with it. Argue over something less pointless.
I have googly eyes on mine. Not only can I definitely find my computer in a sea of identical MacBooks, people across from me at meetings seem to enjoy them.
The Appraisal gem is excellent for ensuring compatibility across many Rails and Ruby versions. Adding it to a project with a good test suite is a pretty good guarantee of an easy upgrade.
Fork, use your fork, send a pull request. Almost every rails upgrade I make forks and send patches on gems that I need that I forgot about. I get good responsiveness and merge rates. Most of the time a gem needs to be able to support multiple rails versions, so in that case I usually send pull request setting up the Appraisal gem to test for appropriate compatibility.
I love notebooks, but I agree with you. I like to use notebooks to instrument and debug modular models. Top down design, which is what I was taught years ago when I was learning C/C++ seems harmful when paired with out of order execution.
Rails is productive out of the box. The author has different preferences for some defaults and some plugins that require config. This is common for a consultancy to have a project like this so their rails apps are consistent around non-default add-ons and preferences.
Rails out of the box is ready to build a production ready project. These are for when developer preferences diverge from the out of the box rails defaults. I love RSpec and I always set that up when I start a new Rails/Ruby project. If you do consulting work, you definitely make new apps frequently and having your favorite things ready to go is a plus. Thoughtbot has a project called suspenders that includes their preferences for new apps.
I admit that for classroom exercises the package manager isn't a huge draw, but when someone learns some JS basics and they want to try to make a real thing, the fact they don't have to move to a new ecosystem to get libraries keeps the momentum high.