Tabish Iqbal

You can use either but stick to one. Yarn I believe was created by facebook as an alternative to NPM due to some issues they had. Yarn is also faster I believe.

check this out Nino: http://jeromedalbert.com/how-dhh-organizes-his-rails-controllers/

umm that seems like a separate app. which means you would have to use rails as api and have the vue app call those rails api

I think that depends Umar, if you are going the route of just having the front end as a separate application and backend in rails (where you will then have api controllers) or you can mix the two bye using something like https://rubygems.org/gems/react_on_rails to add react components in your rails application (https://cognitiveclass.ai/blog/react-on-rails-tutorial-integrating-react-and-ruby-on-rails/)

From Chris's videos on vue + rails thats how I have done it where as I add a vue component into my rails app.

Looks good to me. Maybe avoid all the comments.

PG::NotNullViolation: ERROR: null value in column "name" violates not-null ...

You're probably not adding the name. In your migration you may have that the value cannot be null.

Heres a fix for it: https://github.com/igorkasyanchuk/active_storage_validations

Pretty much.

Weekend well spent.

ashley [5:41 PM]
“model obesity” excellent term, @inopinatus!

This is a software engineering issue not limited to Rails, for sure. It’s interesting to me that there’s never been a group of patterns that have been developed and generally accepted in the Rails arena.

@mclosson re: “Also its a good idea not to use ActiveRecord model classes in migrations to manipulate data. ….” use SQL instead.

I’m not sure I totally agree with that. IMHO, you’re just trading one set of tools for another (Ruby/Rails ActiveRecord vs. SQL), but the issues remains the same.

ashley [2:18 PM]
What are different strategies folks use for handling schema changes and data changes and using migrations? Once you have a production system running but need to do schema changes and data changes or initialization, what are the strategies folks have used, and why?

I definitely know and understand why doing changes to data in migrations is not a good idea. So, then, what are the ways you’ve handled it? How do you reconcile having code that might live ‘outside’ of your system? (e.g. rake files, etc.) Do you keep it incorporated through capistrano or the like?
We’re having good discussions about this on the project I’m working on and am interested in gathering ideas and considerations and lessons learned. (edited)

excid3 [2:45 PM]
@ashley i think the main concerns are 1. what if something fails halfway through, how do you make sure that doesn't break the current running version and 2. how do make sure there is no data loss if something happens

ashley
[2:47 PM]
yup. Also: How far back to you want to guarantee that you can do rollbacks? This is of particular concern with any kind of data manipulation.

excid3 [2:50 PM]
you probably want to make sure things are working in production for a week or so before making it unrollbackable

ashley
[2:57 PM]
Right. That addresses production stuff. And then you also must make the testing data and environments and the developer data and environments coherent. With this kind of strategy, you’re essentially saying “From this point [tag] forward, you must first start with this db schema and this initial data and move forward. And that rollbacks are not guaranteed.” You can only run db scheme migrations forward.

[3:01]
Still leaves open the question: Where do you put data changes if not in migrations? (ex: you add states to some list of all possible states for some object/model; ex: you change the initial state for some object/model)
What if that data change must happen after db migration a1 and then you have a migration later that depends on both the schema change and the data change?
(Yes, the system is still in relatively early stages; new business rules and concepts are being worked through so things can be in flux.)

[3:03]
I don’t think there is just one way (tm) to handle those things. I’m quite sure that there are different strategies that have costs/benefits that you must consider for each project. I guess I’m looking for a list or good write up of common strategies and real world experiences with them. (And also free donuts.)

esparkman [3:20 PM]
blue/green deployments help in some regard

[3:21]
you rollout to one set of server groups, pull them out of your production pool, verify, put them back in, rinse and repeat for the remaining instances

mclosson [3:30 PM]
Also its a good idea not to use ActiveRecord model classes in migrations to manipulate data. Instead you should use direct SQL to manipulate tables and records because the model names can be changed and refactored over time and this will cause the migrations to fail in the future for new developers or deployments. Example:

1. In a migration after you update the schema you try to update all the records like so:
2. Thing.all.each { |thing| thing.update(someattr: some_calculation) }
3. Then you rename Thing to Item in the future, now your migration will fail. Instead you should use SQL like: schema change then… sql = “UPDATE things SET someattr …” ActiveRecord::Base.connection.execute(sql) This way the migration will never fail regardless over the class names.

inopinatus [3:57 PM]
tip re. @mclosson’s recommendation: if you’re not comfortable with SQL or just have a Really Complicated change to make as part of the migration, prototype the query in AR then call .to_sql on it.

[4:00]
personally I am comfortable having data changes in the migration. But I generally prefer to do complex data changes via multiple migrations, in this sequence:

1. Change code so that it will work with both the old and new schema. Commit, test, deploy.
2. Write, commit and deploy the migration that sets up the new column or table structure or whatever
3. Change code so that it only uses the new schema. Commit, test, deploy.
4. Write, commit and deploy a migration that removes the now unused schema elements.

[4:03]
I never roll back in production. I don’t think it’s wise to even try. If you’ve blundered that badly and prod is hosed, it’s likely the rollback contains more landmines that you will miss because you are now panicking. Instead, put up your maintenance apology page, write a fix, and roll forwards. (edited)

[4:04]
Rollbacks are for dev, test, staging environments.

inopinatus [4:09 PM]
Complex migrations are like taking a corner at high speed on a two-wheeled vehicle. If you understand what you’re doing, you can amaze onlookers whilst remaining well inside your comfort zone. If you don’t understand … you’re risking a nasty injury.

[4:10]
@excid3 Maybe there’s scope for a short series on complicated migrations where data and code change in nontrivial ways.

For anyone interested this post talks about how to setup multi-tenancy using uuid's and not subdomains using postgresql.

http://andrewmarkle.com/2016/04/06/multitenancy-with-pundit/

Answer:

1. Add uikit through yarn: yarn add uikit
2. Create a file to be transpiled by webpacker: app/javascript/uikit.sass (or app.sass... whichever name suits you best.)
3. Within uikit.sass import your newly added UIKit library: @import '~uikit/dist/css/uikit'
4. In the head of your app/views/layouts/application.html.erb add <%= stylesheet_pack_tag 'uikit' %>.
5. Run rails s in one terminal window tab and ./bin/webpack-dev-server in the other so webpacker can compile your assets and serve them in your app.

Depends on who your email provider is you can turn on imap and get emails in your app

You should do self joins

http://guides.rubyonrails.org/association_basics.html#the-has-many-association

Go to 2.10 SelfJoin

Congrats!

Stephen

Omg, that worked!
Thats brilliant.

Chris you're awesome. I love you man. (his real words / feelings)

Chris

I haven’t actually used the location header with vue-resource so you may have to access it some different way
or you can put it into the json
nevermind, looks easy: Turbolinks.visit(response.headers.get('Location'));

Chris

just pass the url into location
format.json { render json: @proposal, location: [@project, @proposal] } will probably work too