The lack of even a nod to diversity issues (race, gender, class, etc.) that the tech industry is dealing (or not dealing with) is tone deaf and insulting to the extreme.
Sorry you feel that way - if you take a second to look me up I think you will realize that I hold diversity as one of the most important issues in tech. This is advice that I consistently give people from all backgrounds.
I honestly don't mean it as any kind of personal slight or insult. My apologies that I came across that way. (I'm tempted to edit the OP, but won't for clarity purposes.)
For what it's worth, I acknowledge that many/most of these are indeed applicable to all people. I know you're not asking for this, but the points that jumped out at me as possible opportunities to highlight challenges specific to a wider group (most pertinent bits highlighted):
* Figure out the financial plan. I.e. Do you have enough money in savings, do you have friends/family who can provide seed investment, can you bootstrap, can you reduce your spending and save enough give yourself 6-12 months to work on your idea?
* Often times there are hard barriers preventing people from starting a company. In these cases my best advice is to move to a tech hub (preferably the Bay Area) and work for a tech company until you can save the money, make friends with the right potential teammates, or discover the problem that you are passionate about.
* Producing results isn’t necessarily how you move up the corporate ladder. Internal politics are usually as important, if not more so. <- Noted since it's often more than politics.
I would place class above everything else, and I think it's important to take physical attractiveness (for both genders, mind you) into account. It really feels like most people aren't comfortable with accepting just how much looks matter to them when it comes to judging things like trustworthiness, intelligence, and competency, and how much it affects their ability to like (or dislike) somebody. All very important when it comes to hiring and work/business relationships.
This insistence that everything always has to be about diversity is both insulting and counter-productive. Maybe some of the time we can talk about things that work for all people?
I'll consider myself lucky if I get to work on a project that only creates 49 regressions in 4+ years (which appears to be how far this changelog currently goes back).
> I can't imagine how I would construct a scene with a gold/white dress and then take a picture that looks like the one in the OP
I can. To me, this initially looked like a situation where the background is lit with incandescent bulbs with the dress being in sunlight. In a photo where you have parts of the scene that are lit with incandescent bulbs and other parts are lit with sunlight, correcting white balance for the incandescent part of the scene (yellow -> white) will make anything that's white in the sunlit part of the scene very blue. That's what I was seeing here.
> With a ZNC bounce, a simple ircd server and 5 minutes you can avoid paying for communication and keep your company chat logs secure and on your own infrastructure.
Having watched a coworker spend a solid week getting our company's ircd setup (and this was our VP of Engineering, mind you), I've gotta call BS here. Also, until I started using irccloud[1] a few months ago, I was using ZNC, and that's no walk in the park either.
Agree, ZNC is a crappy experience. The targeting seems wrong here -- if you wanted to pick one feature that developers need that casual IRC users don't, it's the ability to stay connected 24/7, because otherwise the chance of actually being online at the same time as someone who wants to talk about their project is low.
So I'd question the point of building a native client, given ZNC's shortcomings. What's so special about this client that you couldn't just run it as a web service using Node, rather than only making it available as a fat node-webkit client?
I can only assume your coworker had quite an elaborate setup, as most ircds (e.g., ircu, charybdis, ircd-hybrid) take an hour, tops, to configure and get running.
As a novice, it took several hours to wade through the configuration files when setting up an IRCd, and additional time to configure services daemons. I also continually run into issues with configuration decisions I made before using the daemon more actively.
While I could have relied on the defaults, I wouldn't trust my users' data with a default configuration. It would be irresponsible at best, and this is even more important to companies.
> Having watched a coworker spend a solid week getting our company's ircd setup (and this was our VP of Engineering, mind you), I've gotta call BS here.
I've gotta call BS on your story. Unless he was learning Unix from scratch, it shouldn't take more than a couple hours to setup an ircd.
Since a lot of people are saying it shouldn't have taken that long for your VP to set up an irc server (which I agree with), I'd like to argue a case I haven't seen made here. What were your specific needs? Was he setting the server up for just those needs, or what "might be needed"? Both a IRC server and ZNC do not take much to configure for basic needs.
When you start adding features you don't need but think are cool or may one day get used, setting up these things becomes a whole other thing. A IRC server with simple nick auth and chanserv I'm sure would've been enough. What else did your VP implement? A egg drop not? Some other features? There has to be more to this story then you've said.
Yeah, but it's also trivially easy to wrap a 3rd party task in your own task and munge the config at run time. (I'll admit that that pattern didn't become apparent to me until after using Grunt for some months, but once I saw you could do that, many things that seemed onerous got easier.)
I practically live and die by the 5 Minute Rule, and as a counterpoint, I've always found Grunt intuitive, if verbose. In particular, I love that its files API is so flexible. I frequently find myself asking questions that look like "I wonder if I can do this X way", and things just work.
Saying Grunt is "very bad" is harsh and only serves to amplify hyperbole that causes much of the churn around JS tooling.
> Saying Grunt is "very bad" is harsh and only serves to amplify hyperbole that causes much of the churn around JS tooling.
I'm speaking from personal experience and time lost trying to just get things to work so I can focus on building the application, not making a hobby out of building the frontend tooling. What I said may be harsh, but it's the truth. Have you tried gulp?
I have, and I'd even be up for using it on a production project. I'd go so far to say I like it even. But the fact stands that the current project I'm working on has a Gruntfile that just flat out wouldn't work in Gulp - which is a combination of things that I'm doing that don't have an analogue in Grunt, likely mixed with a few that I simply wasn't able to figure out.
If Grunt makes sense on some projects, and Gulp makes sense for others, why the need for all the value judgements? I still stand by the assertion that such claims add nothing to the conversation and muddy the waters for everyone.
I think you underestimate the extent to which SXSW has gone mainstream. There are likely a lot of conservatives who deplore Snowden's actions participating in SXSW.
Totally agree with the "might me good for maintenance mode" sentiment. I'm working on a pre-1.0 project. I'm thinking about the few commits where I was first implementing localStorage caching. Tons of files were effected on each commit. If there was a particularly tricky line in there (there were several), how would I have specified it in a commit? That'd be extremely hard to read when compared to the alternative of putting the comment above the code.
Rebasing locally before "publishing" (pushing) changes to the central repo is definitely okay. It should always be done before pushing the branch for the first time, really, because if someone else has modified develop since you started your branch, you want to make sure your changes are still working and won't break the build (on develop).
