Daniel Fiore taptapdan

A lot of these are outright stolen from Edward O'Campo-Gooding's list of questions. I really like his list.

I'm having some trouble paring this down to a manageable list of questions -- I realistically want to know all of these things before starting to work at a company, but it's a lot to ask all at once. My current game plan is to pick 6 before an interview and ask those.

I'd love comments and suggestions about any of these.

I've found questions like "do you have smart people? Can I learn a lot at your company?" to be basically totally useless -- everybody will say "yeah, definitely!" and it's hard to learn anything from them. So I'm trying to make all of these questions pretty concrete -- if a team doesn't have an issue tracker, they don't have an issue tracker.

I'm also mostly not asking about principles, but the way things are -- not "do you think code review is important?", but "Does all code get reviewed?".

OBSOLETE

This entire guide is based on an old version of Homebrew/Node and no longer applies. It was only ever intended to fix a specific error message which has since been fixed. I've kept it here for historical purposes, but it should no longer be used. Homebrew maintainers have fixed things and the options mentioned don't exist and won't work.

I still believe it is better to manually install npm separately since having a generic package manager maintain another package manager is a bad idea, but the instructions below don't explain how to do that.

Fixing npm On Mac OS X for Homebrew Users

Installing node through Homebrew can cause problems with npm for globally installed packages. To fix it quickly, use the solution below. An explanation is also included at the end of this document.

Architectural Questions

Are responsibilities well defined?
Are the collaborations well defined?
Is coupling minimized?
Can you identify potential duplication?
Are interface definitions and constraints acceptable?
Can modules access needed data—when needed?

Taking your nodebot wifi

Controlling your nodebot using a USB cable is great and all, and obviously you could shell out and grab a sparkcore or some other dedicated controller but what if you've got a standard arduino and you want to take an existing nodebot wireless?

Bluetooth is an option and there's this excellent JohnnyFive wiki entry that will help you there. Bluetooth can be a bit flaky though and it's range is pretty lousy. You can also look at things like XBees and what not using point to point serial, but these are expensive and very fiddly to get working.

Really, what we want is a method of transferring data over a nice, simple, standard method, requiring little configuration, low cost and we can utilise a whole stack of the code we've already produced.

Enter the WiFi232 module. These little beauties are [available from AliExpress for $12 each](http://www.aliexpress.com/item/USR-WIFI232-T-wifi-to-uart-tt

Pull Request Etiquette

Why do we use a Pull Request workflow?

PRs are a great way of sharing information, and can help us be aware of the changes that are occuring in our codebase. They are also an excellent way of getting peer review on the work that we do, without the cost of working in direct pairs.

Ultimately though, the primary reason we use PRs is to encourage quality in the commits that are made to our code repositories

Done well, the commits (and their attached messages) contained within tell a story to people examining the code at a later date. If we are not careful to ensure the quality of these commits, we silently lose this ability.

Auto-deploying built products to gh-pages with GitHub Actions

This is a set up for projects which want to check in only their source files, but have their gh-pages branch automatically updated with some compiled output every time they push.

A file below this one contains the steps for doing this with Travis CI. However, these days I recommend GitHub Actions, for the following reasons:

It is much easier and requires less steps, because you are already authenticated with GitHub, so you don't need to share secret keys across services like you do when coordinate Travis CI and GitHub.
It is free, with no quotas.
Anecdotally, builds are much faster with GitHub Actions than with Travis CI, especially in terms of time spent waiting for a builder.

Remove MySQL completely

Open the Terminal
Use mysqldump to backup your databases
Check for MySQL processes with: ps -ax | grep mysql
Stop and kill any MySQL processes
Analyze MySQL on HomeBrew:
```
brew remove mysql
```

	# The blog post that started it all: https://neocities.org/blog/the-fcc-is-now-rate-limited
	#
	# Current known FCC address ranges:
	# https://news.ycombinator.com/item?id=7716915
	#
	# Confirm/locate FCC IP ranges with this: http://whois.arin.net/rest/net/NET-165-135-0-0-1/pft
	#
	# In your nginx.conf:

	location / {

	Remove osxfuse if installed via homebrew:
	> brew uninstall osxfuse

	Install osxfuse binary and choose to install the MacFUSE compatibility layer:
	http://sourceforge.net/projects/osxfuse/files/latest/download?source=files

	Reboot (optional but recommended by osxfuse)

	Install ntfs-3g via homebrew:
	> brew update && brew install ntfs-3g