Disqus - Latest Comments for jalada

Re: Flight Simulator is currently the highest-reviewed PC game of the year

David Somers — Mon, 17 Aug 2020 05:33:45 -0000

Link to your own review links to Ghosts of Tsushima review :)

Re: Tiny Upstart script to keep a NodeJS process alive

David Somers — Mon, 18 Mar 2019 03:11:30 -0000

Ubuntu uses Systemd now, so probably that.

Re: Heroku is no longer the hobbyist's friend

David Somers — Sat, 17 Jun 2017 21:43:29 -0000

You know you wrote a spam comment about your service on this blog post already right?...

Re: Deploying a Node.js web application with Capistrano

David Somers — Mon, 05 Sep 2016 04:52:18 -0000

Don't get me wrong @mike, I am not suggesting that container-based deployment is better than Capistrano. Merely that the trend is moving away from it. But I think container-based deployment has got a long way to go yet.

Re: The Best Smartphone Car Mount

David Somers — Tue, 28 Jun 2016 03:34:36 -0000

In the UK, the TechMatte MagGrip appears to be the same as this: https://www.amazon.co.uk/gp...

Re: Heroku is no longer the hobbyist's friend

David Somers — Fri, 29 Jan 2016 05:47:53 -0000

The price is not so amazing when you consider how utterly terrible the performance is.

Re: Heroku is no longer the hobbyist's friend

David Somers — Fri, 29 Jan 2016 05:44:58 -0000

That's definitely an option! You really have to think hard about the effort required to deploy your codebase in two places, keeping it in sync, and communicating between the two. By the time you've done all that, why not just host the site there too?

Re: Heroku is no longer the hobbyist's friend

David Somers — Thu, 22 Oct 2015 05:31:46 -0000

Why doesn't Heroku offer the Cloudflare approach anyway? They already know what domain you want, and they already have your certs. If they're making a loss, surely it's in their interests? Additionally, I can't understand how the problems you describe have anything to do with SSL. Isn't that just shared hosting in general?

I agree that Heroku's Postgres offering is strong, but I think a lot of that is beyond the scope (and budget!) of hobby projects, and I feel that it's a massive price jump from their cheaper offerings, making it difficult to find a sweet spot. That's what I focus on in my post: their cheap Postgres is terrible. And for $50/m I might not be able to spend time implementing all the features, but I will get much better performance and storage if I roll it myself.

Re: Heroku is no longer the hobbyist's friend

David Somers — Thu, 22 Oct 2015 05:24:03 -0000

I guess that's a matter of opinion at this point, but I think so :)

Re: Heroku is no longer the hobbyist's friend

David Somers — Wed, 21 Oct 2015 03:55:51 -0000

I don't know if you saw, but there were a huge number of very good suggestions for alternative approaches on the Hacker News discussion thread for this post :) https://news.ycombinator.co...

Re: Heroku is no longer the hobbyist's friend

David Somers — Wed, 21 Oct 2015 03:53:15 -0000

Many projects or ideas fleshed out need SSL and a decent DB. Anything that you want members of the public to try out that uses their data should use SSL. Many interesting projects are ones solving problems with large datasets. Remember the free Heroku DB is only 10k rows.

Simultaneously, a pet project is unlikely to make any money, and is probably coming out of your own pocket, so you're going to be more critical of the service you are getting for the money, as I have been here.

Re: Heroku is no longer the hobbyist's friend

David Somers — Tue, 20 Oct 2015 04:47:24 -0000

But that won't keep me running on the bleeding edge!

Re: Heroku is no longer the hobbyist's friend

David Somers — Tue, 20 Oct 2015 02:59:16 -0000

Except it is rarely $7/month. Add a second dyno (who doesn't need background tasks?), SSL, and a PSQL database with a reasonable row limit and you're already at $41/month.

Re: Heroku is no longer the hobbyist's friend

David Somers — Tue, 20 Oct 2015 02:58:13 -0000

Agreed! That's why the focus of this article is hobbyists who probably don't need to worry about load balancing, VPNs, key rotation, clustering, or complex security policies.

Re: Deploying a Node.js web application with Capistrano

David Somers — Mon, 12 Oct 2015 04:31:10 -0000

Latest trends are much more towards container-based deployment, or git-based deployment (e.g. Heroku buildpacks), or even using Puppet/Chef depending on the complexity.

Re: MiniITX pfSense build

David Somers — Thu, 27 Aug 2015 02:03:09 -0000

Did you get it working? I didn't encounter any problems. Did you get the two interfaces the right way round? Can you see them with ifconfig?

Re: Tips when writing an API in Ruby on Rails

David Somers — Wed, 20 May 2015 05:20:10 -0000

Hi Luca! Thanks for your comment :)

CORS can be used to block requests to the API, but obviously only requests that are made from a browser on another domain. CORS is just a header, after all, so anyone can still cURL your API or proxy it first to use it on another domain. CORS is less about blocking requests you don't want, and more about allowing requests that would normally be blocked. Does that make sense?

You could definitely use Devise for API authentication using the standard session cookie. However that (generally) limits your API to only be consumable by web applications, because handling cookies from another program or server would be a bit of a pain (and isn't what they're designed to be used for).

When using Hawk, I still use Devise! I just generate a Hawk key for each user and then set up Hawk to be an additional authentication method in Devise / Warden. That's not the simplest of tasks, and is a bit of a hack, but if you take a look at how Warden works, it's relatively clear how to add Hawk as another method, it can even work alongside cookie authentication :)

Re: GitLab vs gitolite

David Somers — Tue, 12 May 2015 05:45:16 -0000

That's useful to know, so by disabling nginx in the GitLab config, it won't run when you boot GitLab, and instead you configure your webserver yourself (for example).

Thanks :)

Re: GitLab vs gitolite

David Somers — Tue, 12 May 2015 05:31:07 -0000

I think you're misunderstanding me. I'm not criticising GitLab. Of course GitLab isn't responsible for vulnerabilities in PostgreSQL, it would be absurd to think it was. I'm just pointing out the relative merits of it as a solution.

Is there documentation around configuring the Omnibus packages to use existing installations of Redis etc? How does that affect package upgrades?

Sorry, my last paragraph wording was wrong; I have edited it to reflect what I actually meant, I hope it makes more sense.

Re: GitLab vs gitolite

David Somers — Mon, 11 May 2015 17:17:50 -0000

Just to clarify, I'm thinking here about 'hosting git repositories' as a single functionality requirement here.

Gitlab, even as an omnibus, is not a single component. It is Redis, long-running Ruby tasks, Nginx, and PostgreSQL. Regardless of whether updates are a single apt-get upgrade away, that is a whole host of new infrastructure that an ops team would need to be aware of. They would need to be tracking potential vulnerabilities across all of those pieces of infrastucture, including testing for adequate security, firewalling (if necessary) and so on. And there's definitely a potential for one of those moving parts to have a problem.

Colocating GitLab with other stuff on a server is a separate issue, and on that:

Can you clarify to me, apart from the example you have pointed out with an existing nginx installation, that there are no other conflicts? What if I already had Redis running? What if I was already using Redis for other Sidekiq workers on other apps on my server? What about Postgres? What if my existing Postgres install is non-standard, or I run Redis with authentication on a non-standard port? In those situations, am I not right in saying the Omnibus packages wouldn't be suitable?

So on one side, you have the possibility of using Omnibus packages on a completely empty server, but that is setting up a complete suite of infrastructure that an ops team would need/want visibility on.

On the other side, Omnibus packages aren't best suited to an existing server where you have a lot of similar (e.g. RoR apps) running, and therefore by needing to set it all up manually you will need to manually upgrade GitLab, which is going to require a lot of ops time (in my personal experience!)

Re: GitLab vs gitolite

David Somers — Mon, 11 May 2015 08:28:48 -0000

Thanks Sytse, I do recommend the omnibus packages in my post but I point out some caveats: It's still a beefy application with high system requirements, there's still a lot of individual moving parts and there's still some ops time required to keep it up to date.

Additionally, correct me if I'm wrong, but the Omnibus packages don't play well if you already use pieces of infrastructure Gitlab uses, on the same server, e.g. if I already use Postgres or Redis or nginx on my server for other apps?

Re: Inner Vision for the weekend of April 3, 2015

David Somers — Sun, 12 Apr 2015 12:30:52 -0000

Turning your rice into resistant starch is a really bad idea if you suffer from IBS.

Re: Tips when writing an API in Ruby on Rails

David Somers — Sat, 28 Mar 2015 08:25:07 -0000

If you're doing full stack tests as well, is it still important to be able to test them individually? Is there anything wrong with large controllers if they're manipulating data? I used to try and keep controllers tiny but I found projects are easier to maintain if the business logic and flow is clear inside the controller, rather than inferred by model lifecycles (for example).

Re: Tips when writing an API in Ruby on Rails

David Somers — Fri, 27 Mar 2015 19:25:11 -0000

Good suggestions! What would the benefit be of constructing objects & running ActiveModel validations vs. some reusable `before_action`s in the controllers?

Re: Tips when writing an API in Ruby on Rails

David Somers — Fri, 27 Mar 2015 19:24:01 -0000

Yeah I've used JSON schemas before, in a Node.js application. I'd question the benefit of using JSON at all if it becomes important to type your data like that. You might be better off moving to a different serialisation structure that supports types as a first-class feature e.g. MsgPack, protocol buffers, or Thrift.