Chris Oliver

Roadtrippppps. 🚗

Hey Louis-Philippe!

The goal is certainly to help you upgrade Postgres and Redis. One of the tricky bits of this is that often times your code will be affected by this, so I don't want to accidentally break your apps.

Once there's a major version update, I'm going to be working on a script to help you do the migration as seamlessly as possible. The process is usually pretty simple for Postgres where you only have to run a couple commands to stop the old database, migrate it to the new version, and start the new version. You can see the process here: https://gist.github.com/delameko/bd3aa2a54a15c50c723f0eef8f583a44

Redis is similar, although, it's probably easier to upgrade than Postgres which is great.

Hatch won't take over full control of your servers like Heroku does, so you're free to upgrade things at any time or make changes as you like. At the end of the day, I want you to have full freedom to run what you want and have Hatch just make your life a bit easier so you're not dealing with the hassle of server management constantly.

Hey Karim! Excited you're moving to Hatch!

Jack's answers are all spot on.

1. There's a gem called Backup that Hatch helps you setup for each app. You'll need to login to your server to edit the config if you want the backups to upload to S3 or something, but it's really easy to use.
2. I haven't used Delayed_job on Hatch yet myself, but I believe someone has already. The important thing will be to basically add these commands to the deploy script (and make sure you've got that daemon gem installed). https://github.com/collectiveidea/delayed_job#running-jobs If you run into any troubles with this, let me know and I'll help you get that situated. I generally recommend you always use Sidekiq these days over delayed_job, resque, etc so this feature is a little less tested.
3. Like Jack mentioned, RAM is going to be the most important thing here. You'll generally want a 1GB or 2GB server. If you don't know, you can start with a 1GB server and DigitalOcean makes it super easy to migrate up to a larger size if you start getting memory errors.
4. Hatch has two cool features around logs. First, you can actually view the logs in the web UI by clicking on the "Rails Logs" tab of your app. It will retrieve the logs for you and you can read the last like 300 lines or so. Second, because logs can get unweildy, your logs on the server are rotated daily so that you don't run out of disk space. Every day they get compressed and labeled with the date so if you ever need to go back into the logs for a couple days, you can SSH in and find those.
5. A little bash script or alias will do the trick for you like Jack mentioned. This would be nice to add to Hatch's UI so you could copy and paste that into your Bash or ZSH config. 👍

I like that aproach. You could certainly simplify your routes file and that would take care of things in a much nicer way. Loading the yaml file in an initializer and looping through it with some ruby in the routes file should do the trick really easily. And it's super flexible so you can change the format or whatever you like easily in the future.

That works. The other thing you can do is look at @articles.total_entries I believe with will_paginate which will give you the count of all the results, not just the current page. It's either that or total_count on that or Kaminari.

Your solution is simple enough though so I would stick with that. 👍

You're definitely doing something that is outside the scope of most pagination gems. What I would probably do is customize the view template to only show the last 5 pages links. This would visually make it so you could only see the first X items and then you can have your controller also verify the page # is between 1 and 5 so the users can't go outside those boundaries.

What does your solution look like right now?

Hey Simon,

One super important thing here is that pagination uses both limit and order to make pages. When you add limit in on top of that, you're going to likely break pagination because of that.

Are you trying to limit the number of pages displayed?

Congrats on releasing your app Adrian, that's incredible! I can't wait to check it out. Looks really well done.

Thanks so much for the kind words guys. Couldn't make me happier to see that my little screencasts have helped so much. You guys are awesome. 🍻

Hah, good catch. Thanks for the heads up on that.

The cache directory is exactly what you would imagine. When you're uploading a file with a form and the form validation fails, you want to keep a cached copy of that file temporarily until the user completes the form. You don't want to permanently store the file since the form wasn't valid, so you just need it temporarily stored somewhere. Hence the cache directory. When the validations pass, the file is simply copied from cache to store rather than re-uploading the file.

Yeah, the proof of concept part helped me for two reasons:

1. It greases the wheels. The clients know you're not trying to gouge them for all they got.
2. You get to back out early if the client isn't good to work with.

Roughly my daily and weekly pricing was based upon hourly pricing. Say like $100/hr equates to $4k for a 40 hour week. Chances are you're not going to be booked every single week of the year so the weekly price is high enough to account for time you're doing sales and taxes and other expenses you may have. If all goes well, you should be making a six-figure salary doing that.

The daily and weekly stuff was usually for ongoing projects. Say a couple months down the line after finishing a project the client comes back with some maintenance problems or revisions. This pricing makes it fairly easy for you to say okay cool, I'll tackle those things and it'll cost $X per day. It worked best when you couldn't quite judge how much time something was going to take which is where flat fee is riskier.

You're definitely right about picking a number of how much you want to make being the best way to decide what to charge. I think roughly the easiest way to break things down is to work backwards. If you want to make $100k/yr (keep taxes in mind), you're going to want to make basically $8300 a month. That's $2075 a week, $415 a day, or roughly $50/hr. Things that you have to pay for that an employer wouldn't pushes that number up (health insurance, taxes for self employed, office, internet, computer, etc) so you'll want to add those into the calculation. It's good to budget for buying some new computer equipment each year, and so on, so you'll want to tack those on top.

Another thing to think about is that often times you're going to be in one of two modes: Sales mode or Execution mode. Usually you won't be getting that many new projects while you're doing work for someone. I generally got new projects when I was nearing the end of a project and was taking more time out to go to meetups and talk with leads. When I got a project I was usually heads down working and so things tended to go in phases to keep the pipeline of work going. Referrals are always the best source, but you have to do really good work to make that work and your clients need to know other potential clients.

And of course, you have to be actually worth those prices you want to charge. It's not hard to work your prices up with experience, but a junior dev trying to charge $100/hr is going to struggle making clients think they're worth it. That's a lot of money. If you think of it from the flip side and consider paying someone to build one of your apps for $100/hr, you're gonna want to make sure they aren't slow or mediocre at what they do. The way I dealt with that was starting out charging $25/hr, taking on tons of work and each new client raising the prices slowly by like $5/hr or so. My slowness was accounted for (or I didn't bill for some hours) and the clients were happy and while I didn't make as much money as I wanted, it was exactly what I needed to work my way up to higher pricing.

This makes me want to do like a course on consulting or something. I think that would be really fun to do.

This is looking pretty good. I think the tough spot now is that you need to set the update to set the tasklist_id as well.

I think this should work:

def sort
  @list_id = params[:list].first
  @items = params[:item]
  @items.each_with_index do |id, index|
    taskitem = Taskitem.find(id).update(tasklist_id: @list_id, position: (index +1))
  end
  render :nothing => true
end

Hey Alexander, I don't know the PayPal API very well, but they own Braintree and I have done an episode on that: https://gorails.com/episode...

Braintree lets you do both PayPal and credit cards so you can pick whichever you need. I'd recommend using it over the PayPal API directly for most all cases.

Ah I see, kinda like Trello board columns. I believe you would want to make sure you submitted the tasklist for the one that the item landed on. You would probably need to check that and see what $(this) references, whether it was for the column it was picked up, or the column of where it dropped. Then server-side you can take those items and make sure that they're all updated with the correct tasklist_id which would do the moving of the item between tasklists on the db side.

This might make for a good screencast.

Hey Arjun!

This is a fantastic question. I had a bunch of different methods of doing this over the years and yours sounds very much like what I did.

What I finally ended up with was charging a flat fee per project. This worked because I generally had a long in-depth conversation about what needed to be built and charged extra to account for any changes that were likely to come up. If things deviated too much from the original plan, I'd usually have to cut the project off at a point and renegotiate things. This didn't happen often, but it was a concern. If you get done early, you make more profit. This is the big plus that the other hourly, daily, or weekly options don't really have, but you can also lose money here if you screw things up.

Another option I did for more open ended projects was to do weekly or daily pricing. They could buy chunks of my time and that works out really well. I know my budget and availability and they can budget as well for things.

One thing for me was that I only did the building part, so you've got to also account for the Wireframing, Design and Slicing parts. I can imagine that those have a lot more back and forth with the clients. Generally I had someone else doing the designs but I might participate in that part helping to improve the flow of the app and everything.

As for budgeting things, I'd usually try to find out how deep the customer wants to go on things and what their budget was. I'd tell them that their budget dictated a lot of what we might build. Since I worked for a lot of startups, we might start out with a small $2k-5k project to make sure we work together well and that what we were building is on the right track. A proof of concept if you will. It helped align their ideas with how much money would be required to build their bigger vision stuff as well and I knew that if we did a good job on the first project, we could work again on a larger one.

Hey Chris,

That's a good question. Honestly the Railscasts episode is probably the most recent that I've seen on that. http://railscasts.com/episodes/147-sortable-lists-revised?view=comments

I should do an episode on it, but I don't think too much has changed. The general idea is that you will keep track of the sort order in the db and then when the user drops an item, you tell the server to update all the positions of items accordingly.

That would make for a good episode. I'll add this to my list. Luckily most of them, even Twitter, now provide email address.

The rough idea is that you should save the omniauth auth info to a cookie, and then redirect the user to set their email and save it all together.

I noticed that a bit earlier today. Got a new computer to record on though so I've lost my old Screenflow settings. Possibly something with their export options that wasn't rendering at the highest quality.

Thanks so much Nick, you've always been a big supporter! 🎈🎈🎈