tombell

I've never had an issue running binaries written in Go I've compiled myself. From what I've experienced, only appears to affect .app binaries.

should be 141 if you want to print out a string that would be 140 characters, NULL termination is a thing.

There are so many lines in the post series that don't make very much sense if you understand the YC program.

We'd aim to have 4 to 6 developers on the project within the first few weeks, and had a substantial budget to achieve this.

What budget?

The hiring process began immediately with advertisements going up on social media

As the CTO, would you not be able to contribute more to this project?

One of the huge benefits of the YC program is the ability to experiment with scaling ideas.

Talking about looking into scaling before having anything usable or users? Time would have been spent better actually building a prototype to prove the concept.

As the first Demo Day approached, despite being a director and CTO, I was instructed not to attend due to not being part of the initial interview process.

I kind of suspect at this point in the post series, that the author wasn't really a "director" or "CTO".

After reading the lessons in the third post, sounds like the author just jumped at the chance to be part of YC without much knowledge of what he would actually have to contribute.

Yes, the public API for a library that the developer interfaces with. Not a web APi.

They may also have internal apps written using Swift which are not public. However it's also nice to have a public style guide.

I have my GitHub profile, but it doesn't have much on it except a few random open sourced projects and some random open source contributions. A lot of other work is for past/current employers which I can't exactly show off easily.

If you built an app knowing it NEEDS push notifications on a platform where it's optional for the user to enable/disable, you failed as a developer. The application should be able to function either way. Users deny getting their location? Ask them to input a location instead.

Even if you change one post, you still need to 'rebuild' every thing. I can't see how this can be reduced.

It's a static site, you have no idea what files depend on each other. So everything has to be rebuilt.

"The commands will trigger a webhook call to your server, where the actual deployment/testing/whatever command you need takes place."

The end user still needs to run something on their servers to actually do anything for their custom commands, which is essentially what hubot scripts do, which is what my book is teaching people about.

So you came here to advertise your own product in a post about mine?

You're basically deploying a thing that'll send http requests to another server which then executes specific tasks. So you've essentially replaced hubot with a web application on the end users servers.

What is the difference?

Yup, I plan on writing a pretty detailed section in chapter 4 about the hubot brain. Redis is just the default backend for persisting the brain.

I'm trying to understand which part of my book you're trying to 'avoid'. Because from what I understand it's just the deploying bit? Which my hubot-factory already did, and it is being improved for a new version with the help of a great company. You've also essentially made script writing even harder than it is for hubot.

How does one go about writing their own commands for a hosted product?

This book is a work in progress, feel free to open an issue on the repo to suggest things you want to see added, and I'll add them!

I recently added a HTTP route to hubot `/hubot/help` that you can visit if you enable the HTTP support to view the help on a page rather than flood channels.

The only issue I have with this is having to type 'octogit' as a command or alias it, compared to 'hub' or 'git'.

So the Mafia are hiring Rails devs, cool I guess? How about people just move on and care about something more important... like beer.

Ctrl (or Cmd) Click, done.

You're still coding in assembler I assume?

> I disagree, he was simply posting comments about a professional athlete on his own twitter account, it's not like he was yelling it on the street or putting up billboards.

I think you'll find, posting it on Twitter is the same as getting a tshirt with it written on and walking on the streets.

> So, the answer would be to never scrap features (that's why you did proper design beforehand, right?).

Sure, if you work in some sort of enterprise or corporate environment.

So you end up with a bunch of commits in a random order relating to different things.

Lets say person A and person B are working on two features both committing to master.

Person A commits some work to master and pushes to origin. Person B commits some work and pushes to origin. Repeat this a few times, now you want to scrap the feature person A is working on. How do you cleanly handle this?

Tagging is useful for libraries and such. But for web sites and the like, you can just use the deployed commit SHA as an identifier. Much like GitHub does https://github.com/site/sha

I prefer keeping unfinished features out of my deployed code base, so I keep them in branches.

Even if all tests pass, it doesn't mean you're ready to ship half-completed features. The features should be on branches not in the deployable code.

A branch is just a pointer to a commit. Once you've merged/rebased your branch into master, why would you keep it around?

A long running branch is usually a feature branch that is worked on over a long period of time. Just committing everything to master is asking for trouble.

I feel the need to point out the obvious. It's LEGO not LEGOS or legos.

It's actually fairly simple to get running locally, I'll take a look at improving the documentation.

1. Download the latest version from the downloads section

2. Install dependencies with `npm install`

3. Export any environment variables for your adapters and/or scripts

4. `bin/hubot -a <adapter>`

That's as simple as it is to run in a terminal. You can use many things to manage the actual process e.g. Foreman/Upstart/Forever.