Chris Oliver

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.

Yeah html-pipeline is an awesome gem.

If you want, you could probably build an HTML::Pipeline plugin to handle Wiki-style links pretty easily. Look for a specific syntax, parse those items out, look them up in your database by title, and replace them with links to those other articles.

On the other hand, you could probably reclaim one of those gems and maintain it.

I'd probably shoot for the HTML::Pipeline plugin because it would be simplest and Markdown already gives you everything else you need. This would definitely be cool to see. Might make for a fun screencast on building an extension too.

Oh perfect!

I actually just remembered, Rails provides a helper called simple_format that should do the <br/> replacement for you.

You may also need the <%=j at the beginning of the tag so that any double quotes in your string are escaped so it won't interfer with the Javascript. I put that in there as well just in case.

$("#assignment_conditions").empty();
$("#assignment_conditions").val("<%=j simple_format @company.conditions %>");

So one thing is that \r\n in HTML won't show up as newlines. If you're trying to get those newlines into the HTML on the page, you'll want to replace those with <br/> to force the breaks.

Another thing to note is that normally the newlines are just \n and \r\n is basically just used on Windows for newlines.

You should be able to just do a gsub like this:

$("#assignment_conditions").empty();
$("#assignment_conditions").val("<%= @company.conditions.gsub("\n", "<br/>") %>");

Replace the <br/> with \r\n if that's actually what you need.

Nope, This should be all you need.

Yes, Ruby and Rubygems get updated at different times. Everything looks good there but you should upgrade to Rails 4.2.1! :)

When you register for Mandrill, you have to sign up with an email address. That's the email you will put into the user_name field so it knows which account is sending the emails.

I don't think I've touched that for a bit. If you see it broken, send me a screenshot and I'll make sure to correct it. They should definitely be on the index page.

Good catch! That should actually reference @params in the PORO because it doesn't have access to lead_params in there unless you move that code too.

I think if that all happens server side, you should be fine. Since the session is encrypted, storing the token should be safe there. This is basically how login with mobile apps works. Make sure you're sending the token over SSL so it's not publicly accessible over the network and it's usually best to set an expiration on tokens if you can.

Devise is its own authentication system. If your registration API is in the PHP app, you won't be able to use it and you'll need to write your own code to handle that instead. Devise doesn't talk to APIs for authentication, just the database.

If you're putting the user authentication in the new Rails app, then you could use Devise.

Make sense?