Chris Oliver

I'm not quite sure how the AWS storage works with the resized images. I'm guessing it downloads a copy of the image to your server from S3 and then resizes it, but maybe it's slow to reprocess things.

I wouldn't consider myself a refile expert and I'm not using it in production anywhere, but I would post this on the Refile github issues: https://github.com/elabs/refile

I haven't yet, but really want to. Obviously the HTML to PDF will be way easier than how Prawn does it. The programmatic generation is no fun at all.

This is basically saying that you're not using the rbenv version of Ruby and you're using system Ruby which you don't want to do.

Try restarting your terminal and double check your ran all the commands. The output you should get from the "which ruby" is something like this "/Users/chris/.rbenv/shims/ruby" when it is set up correctly.

I think current_clock_event probably makes sense in the controller because you might need it for rendering in the views to remind the user it's not finished. Like you said, you'll need to be able to reference it from the model for proper scoping, so you may technically need it in both places if you add it to the model first and then make a controller method to make it easier to access.

It make sense to cache the value of total_hours on the model after save so that you've always got a queryable value. Would definitely recommend that.

I think most people have opted not to build a native app that's just a mobile browser because it doesn't provide a great experience.

That said, it's still the easiest way to go. I believe if you use something like Phonegap, you probably do not need to do as much with regards to building APIs. You basically just need to store the session cookie around so next time you launch the app the user is still signed in.

If you'd like to go the full native experience, you will have to do a lot more work with building the apps and the APIs to support them.

Are you leaning one way or the other?

That was another really fantastic talk. All of Sandi Metz's talks are wonderful.

Congrats!! Glad you got it working even if it did take a few days ;-)

The first few setups I had with nginx had a bunch of the same problems. Eventually you start to realize what works and troubleshooting gets a lot easier. There are just so many moving parts, it can be hard to figure out where things are going wrong at the beginning.

Here's a question: do you have database migrations in your app?

Also this error is saying development and you probably want production. My mistake on that nginx snippet. You'll want to update that to say production instead. This might be the cause of why nothing ran.

When you run the migrations with capistrano, you should see the migrations printed out in the logs when it works correctly.

Alright! Now we're onto something. I think what happened the first time was that Passenger wasn't actually serving up the homepage through Rails and instead it was just serving up a static file instead directly. This is good.

So now your database migrations need to be run on your server which you can do with cap deploy:migrate

Once that is done, then I think Rails should successfully boot and serve up your pages.

Ah! This makes much more sense. It's not Rails, but your nginx config that's wrong. I was a bit confused how Rails wouldn't be responding to those properly.

You might try simplifying your config there to this and seeing what happens:

server {
  listen 80 default_server;
  server_name 198.199.98.206;
  passenger_enabled on;
  passenger_app_env development;
  root /home/deploy/resume/current/public;
}

See if that helps at all, if not there are a few other things we can check.

Got some links or code we can take a look at? I bet it's something pretty simple but one of those differences when deploying to production.

I think it makes sense to have a ClockEvent that has both in and out events. It also sticks around so that you can remind people to clock out if it's past a set amount of time and they have an open ClockEvent because they forgot to clock out.

Calculations on that should be as simple as subtracting the out from the in times and you'll get your result in seconds which you can easily add up and convert to hours. It will also easily work across days and things like that.

current_clock_event Could just be the last ClockEvent for the user where(clock_out_at: nil) It would return the last incomplete one, or none at all so you could create a new ClockEvent instead.

I think you've got this pretty well thought out so far. The only thing will be handling the forgotten clock outs and how to remind users and set the actual time for it after the fact.

I thought I'd start a thread of articles and videos that are super high quality for software developers. Things that make you think and improve your thinking and how you build products.

I'll start:

https://signalvnoise.com/posts/3874-poison

Gotcha. I guess if the responses are super slow because of that, then having separate resources for them makes sense so only certain requests are slow and you'll be able to load the regular data for the primary record quickly.

I wouldn't put the token in the url because it's not a resource itself.

One benefit of having the fields in the query is that your API endpoint will not change in the future. You can always include more data simply by adding options. If you have /resource/dog, /resource/cat, etc your clients will need to be aware when these are deprecated, move, or new things are added. It's much less flexible than having a configurable fields or includes query param.

I guess my question is actually more related to performance. How are you handling the slow responses for those records? Are you just providing a really slow response to an API request? Are you sending webhooks at a later time with the result?

Since you're basically filtering the results, this makes more sense as a query param than an endpoint (in general).

I don't think either approach is necessarily "more RESTful" than the other. It depends on the use case of this stuff. If the dog and cat are truly separate objects with their own sub-fields, then it might make sense to have their own route if there is a use case for retrieving that with nothing else. On the flip side, if cat is just one field, then making an endpoint just for this doesn't make sense and isn't actually RESTful because it's only a piece of a larger object.

The fields parameter is straightforward. If you have fields you always want to return, you could have an include parameter that they can include additional fields that aren't included by default. This would let them specify only the extras they need rather than having to specify every single field each request. That may not be what they need, so specifying individual fields might make more sense. That's up to you. In general, the right answer is going to come from your understanding of how this will be consumed.

How are you handling the slow responses from the backend with the image storage?

That's awesome!! :) Sounds like everything came together really, really well.

Don't worry about doing TDD too much. Having functional code is the most important and you can easily add tests in as you find bugs in production.

I'd love to see you tackle one of those gems. :)

I think I'm going do a screencast on building an extension to html-pipeline for this feature next week. It's a really good example of something people might want to do and gives you a whole lot of functionality that you can have without implementing some other random gem.

Thanks! Fixed that link.

This turned out pretty sweet. While you can definitely clean it up, as a first pass, this is simple enough that you can easily refactor it later as it grows.

I think that having your scopes, descriptions, and other metadata organized will be useful. It will help you remove the case statement in your controller and that's going to help a lot by defining everything in one place.