Chris Oliver

I believe if you want to do iOS development at all, you have to use macOS. You can run it on some compatible PCs though: tonymacx86.com

Having spent the last few weeks doing some React Native on the side, it's a pretty rough experience. Lots of compatibility problems and things like navigation libraries have been rewritten like 6 times already. It's still got a long way to go and it's getting better, but it can be pretty frustrating compared to just building native apps with or without Turbolinks adapters. At least when you're building native you can easily use any library or examples online.

Just as a heads up I just published this week's episode on this topic. :)

Archiving servers, deleting apps, and deploying to a custom VPS are now live! Things may still be a little buggy, but it's ready to try.

I'm using easyAutocomplete for the global search on GoRails. It just makes an AJAX request that queries episodes and forum threads and returns a JSON object of two arrays, one for each and those get displayed accordingly. I'll try to do an episode on this soon.

Just wanted to give you a heads up, I've got app deletion almost ready and that will becoming out this week hopefully alongside the custom VPS option that will allow you to make deployments on any VPS, not just DigitalOcean. 👍

You can definitely do all of that with typed store and a json column. Like I showed in the example, it casts both going in and out of the store, so there's no chance you'll have booleans with 5 states.

One better example is probably feature flags that will often come and go. Adding and removing columns for every feature flag is going to be way overkill for something that can easily be handled through a store.

As far as I know, yes it's still the go-to. Messaging doesn't change that much so I wouldn't expect a whole lot of change for it.

I believe that JSONB is probably the best format for this because it's a binary representation. Should be more efficient for most everything. There's some more information on this stuff here: https://www.citusdata.com/b...

An interface is the public methods on an object you define so that other code can interact with them.

You can as long as you're using hstore or json column in Postgres, but it's not quite the normal where syntax like you mentioned. You have to use the SQL syntax I showed in the episode for querying JSON columns (note the "->>" part at the end).

Hstore has its own syntax as well that's a bit different and uses "@>" and some other syntax.

That's exciting Sean! I did this back in 2011 for a job and had the same 3 hour window thing.

For me, I was given 4 or 5 CSV files that I had to parse and then run searches against. It was pricing data, searches, gps locations, and stuff and was quite a hard thing to solve in 3 hours, especially for my first job. I got super close but didn't have time to write any tests and my answers were close but not quite correct from what I could tell. Ultimately I didn't get hired because they were on the fence with my results but I learned a lot from it.

My big takeaways from it were:

1. The biggest thing is to stay as calm as you can and share your thought process. If you don't, you're going to write a bunch of code that's semi-disorganized and makes it had for them to understand how you were trying to approach the problem. The best way to share your thought process is through well organized code, but take your time to comment / write out your ideas as you go and turn that in as well. You can outline which pieces you'd break down and separate into different parts, which you'd tackle first, and so on. Also note the pieces you see are complex or you think could be solved better and how you might come back later to improve them.
2. Do your best to write out all your objects and interfaces for them as clearly as you can. What ones will you need? what is each one's job? how will they interact?
3. The previous questions are a good foundation for thinking about how your objects would be tested as well. Even if you don't get around to writing tests or anything, showing that your objects are designed to be testable will be a great sign.

This is awesome, thanks for sharing that John!

Yes definitely a feature that's coming soon. I wanted to make sure I safely did these and didn't cause any major issues when I implemented this. Some people will want the db removed, others might not, and so on. I think I will likely remove the app and the Nginx config, but retain the database on your server so you don't lose any important data.

You can just listen to the charge.failed event and send an email accordingly if you want. Even better, you can use a service like Profitwell to handle the failed payments (and soon to expire cards) for you and let them optimize the email text and things. That's what I use and it's generally better at recovering failed payments than your own stuff because they can learn and improve over a vast set of businesses rather than just your single one.

I do what I can. :)

Yep. And here's the link to the redirect_to override from the gem: https://github.com/turbolin...

If you ask for JS back and you're using Turbolinks, it will actually send back a Turbolinks.visit() to redirect you on success which is awesome and means everything is handled like a single page app. You still have to handle the JS side for failure, but there's some talk about having that automated as well with some changes to Turbolinks to replace the current page with the standard re-render on failure. For now you have to just insert errors on the page manually.

You can always just grab the url from the wrapper form. The reason I didn't do that in these episodes was the rails_ujs library was doing something weird with the button clicks and so I left it out. Normally I would just use Rails to render a form tag and then use Vue to make it work, so then on submission Vue can just simply grab the url from the form (and csrf token too).

In that situation, I would probably just leave the JSON alone, serialize it with the wrong names, and then at the very end go through and rename those properties. You could do that on either side as well, in the JS or in the controller. It wouldn't really matter, but it might be easiest to do in JS.

You know, I don't believe I ever got around to it. Going to record it this week.