I stopped going back after I realized it was a homogeneous group (read: white dudes connected to VCs) patting each other on the back for releasing half-baked MVPs. I was really turned-off by that.
That said, I think it's slowly changing for the better (rigging allegations aside) since I last took a look a year or so ago. I received a small amount of traction after submitting a stupid iMessage sticker pack I built. I was still pretty salty when I submitted it, but was curious to see if the exclusivity had loosened up a little bit. It had!
As someone who occasionally builds silly apps it's cool to share them with a community of makers, but I don't think PH fits the bill anymore. Maybe the acquisition will allow them to re-focus?
I totally agree with you, but in birracerveza's dead comment he strongly disagrees without offering any explanation: "He is explaining the reason that he stopped going, and bringing race into the mix. That is racism."
No, that is not racism, but "many people" think that way because they have been wrongly taught to believe that any mention of race is racism, which is incorrect.
And birracerveza is one of those "many people" who really need to educate themselves by reading up on the topic of racism, starting with "Mentioning Race Doesn't Make You a Racist [1]", and continuing on to wikipedia [2] to learn what racism really is.
Hint: Ask yourself if Cbeck527 systematically oppressed anyone by "stopping going" or "bringing race into the mix"?
It's not about race. It's about class. The "connected" part is what matters, not the "white dude" part.
Your average 99%er white dude does not get funded in Silicon Valley. He gets asked where he "summers" and then walks out confused.
What matters in Silicon Valley is being wealthy and having attended the right school. Being connected matters more than anything.
The only thing that makes it somewhat meritocratic is that real success is undeniable and even unconnected people can find ways to succeed without help.
I see your point, but don't necessarily agree 100%.
Regardless, I was calling it as I saw it at the time. Checking out the comment section of a few posts on PH's front page today, it looks like my evaluation still stands. Though my classification may be hyper-specific, my main point is it's a microcosm (stereotype?) of the echo chamber.
I don't know why many people operate under the delusion that the value of their work is the same as how valuable you are perceived. Not to say that there's no correlation, but it's just part of the equation.
People pay a premium for doing business with other people that they like. It's perfectly logical - we all want our daily interactions to be pleasant ones, and would much rather work with people we like than people we find distasteful.
It's completely counter-productive to frame this as everyone else just being superficial ass-kissing hypocrites.
You're right, it's less about ass kissing and more about cultural fit which is kind of a dog whistle but not exactly since you can hang if you're a "cool" Indian dude who drinks beer and plays ping pong, beer pong or foosball and doesn't smell funny.
Wow, congrats, you got a like from us. We haven't been featured yet, but two of our images have made it on the new page. And they got a lot of views and downloads.
Eiriksmal's post nailed it. I used the Canon 40mm[1] pancake lens (one of my favorites!) and my 5dMkII. That pic was the final night that I was in California[2]. I took a nap and slept through the time I was planning to go to the bridge, but ended up catching the last few minutes of light.
Shot on a full-frame DSLR, the Canon 5D mkII, 40mm, f6 @ 1/320. ISO 160. It doesn't look like any filters were used and the fast shutter speed casts the bridge in darkness while letting the setting sun's colors come through in the sky.
> "It remains virtually impossible to create a Ruby or Python web server virtual machine image that DOESN’T include build tools (gcc), ssh, and multiple latent shell executables."
At work, our tech team has found an interesting way around this for our Python app. We build out the virtualenv in the docker container, and then run our ansible-based deployments inside the same container. With that, our virtual environments are rsync'd to the app servers so we can avoid installing developer tools.
I'm ditching virtualenvs and going with old good Debian packaging and private APT repository.
For VMs/containers that already run a single application, except for some weird edge cases, there's really no point in having a virtual environment in a virtual environment.
I have initial success with a few simpler projects, now looking into transitioning more complex ones. Not sure whenever it'll go without any hassle, but seems worth trying. At worst, I'd just waste my time and return to virtualenvs.
One reason to keep virtualenvs is that the system Python (VM or container) includes extra Python packages that your app may or may not need. If you use a virtualenv, you exclude these system-installed packages and guarantee a clean starting point.
I find the problem with this approach comes when you want to ship a package (ie: requests) that is newer than whatever is packaged for your OS. Then you either have to repackage OS packages, taking on the corresponding duty to keep them patched. I am using wheel files in production for this very reason
Same here. As a bonus, it makes it easy to create a bare-metal OS installation image that includes your app.
I'm running a script right now that generates an ISO that turns a brand new machine into a server running our app with a template DB in completely unattended fashion.
I don't know what you consider an unwieldy chain of build steps, but for Ruby it's simply a matter of building the container, and run it with your app directory (or a suitable build location) mounted as a volume, install dev-dependencies then executing "bundler install --standalone --path vendor", and subsequently using that as the basis for building the final container image.
You can make that cleaner by making the build steps into one Docker image, the final app into a second, and have them share a base image that contains all the basic dependencies.
For Ruby at least the intermediate build step would typically only need to be re-run whenever your Gemfile/Gemfile.lock changes.
Yes, so the attack vector is still higher than other solutions outlined in the article, but we've managed to avoid installing stuff like gcc. It's also significantly cut down our deployment time, especially when updating libraries/requirements.
There are even fewer regulations preventing Uber drivers from declining a fare based on location - or race, or gender, or they don't like your sports team, or anything.
