damoncali

As always, dig deeper. Tesla isn't out of the woods yet.

Perhaps that's an additional factor - not exactly confirmation bias, but not unrelated.

There are probably other minor differences (I want to say there were some electrical interface issues), but that was the part that impacted my work.

I recreate the view directory structure in the assets folder, but only for views where I need a complex (angular) UI. So I might have a file in assets/javascripts/users/show.js because the users#show view is more complicated than I want to do in rails.

If that asset file exists, I have a helper automatically load it into the head section of the view layout when the users#show action is hit. The helper itself is only a few lines of some obscure rails code that looks up the name of the controller, action, etc and looks up the files in the assets directory. If you match the view directory structure to the assets directory structure, it stays very organized and is all done by convention.

In the show.js file, I will create an entire mini angular app (one file). The show.html.erb view will just contain angular markup (and maybe some erb). It's that simple. If Angular needs some instance variables from rails, I just pass them in to js with a couple lines in a <script> tag at the beginning of the view.

If I need a custom directive, I put the templates for those in public/templates (there may be a better place for these, depending on what you're doing - for my use case, this was fine).

There are some downsides - you have to separately compile each js file. I suppose you could do them all together, but I like keeping them separate. But largely, you can lay angular on top of rails in a very unintrusive manner this way. It probably doesn't work for every situation - you have to keep your angular apps small or it gets complicated again. But it really lets you enhance the UI of a rails app without a lot of technical debt. Code reuse can be a challenge (organizing bits that are shared is kinda wonky), but often the angular apps are small and simple enough that this isn't really a problem. Repeat yourself a little. It won't kill you.

An example of where I've used it is to load a chart and some daily/weekly/monthly selectable data that is sortable by columns, by date, with pagination, search fields, etc. I make the data available via rails as JSON, and just have the angular app pull it all in for the user to manipulate.

Another would be a form that creates a query interface similar to the one used by google analytics to create custom segments.

There may be better ways to do all this, but this approach has served me well. It's a little rough, and I'm sure it could be improved. As always, YMMV.

Railscasts was active. This was huge. Repeating for emphasis. Railscasts was huge for me.

There were a few headscratchers along the way - RJS, components, maybe a few other oddities (I think turbolinks falls into this category), but they tend to get removed as time goes on if they don't work for a lot of people. The Rails team may get pretty enthusiastic about some weird stuff now and then, but they're also pretty good about reversing their mistakes. They seemed to have learned from the 2->3 transition hell as well. Upgrades are fairly painless now.

That said, it's still very much relevant. It's been polished to the point where you can really do a lot with very little work. There are solid, well maintained gems that do lots of common tasks (although there are a few things that are strangely missing from the community). The REST convention is very powerful, and the code is easy to follow.

I resisted the move towards complex js front end frameworks because I was tired of figuring out which one to learn. That hasn't changed. I abhor the pace of js framework development - I can't justify learning a lot of it from a business perspective. It is just too unstable. I have clients using Rails apps I wrote 7 years ago that are still very maintainable, and that is great.

When I need complex UI's I take a hybrid approach and have rails load miniature angular apps on a page by page basis. If the view is complex enough, I have it load up a single file angular app to handle that complexity - but only for that page. A 4 line helper loads the angular files automatically. Otherwise, it's all Rails. I've found this approach to be very flexible - it's able of delivering a very rich UI where needed without overcomplicating the good stuff that Rails provides for free.

Even if I were starting over today, I think Rails would be at or near the top of my list. I feel for folks picking it up now, though, as it is a little tougher than it used to be.

That and company value is the present value of all future earnings, where "industry size" is typically understood to be an annual revenue number. Apples and oranges.

The realization of the ideal that you can just get a percentage of the company for putting in your time working hard is largely elusive. I think that is the problem to solve. I'm not terribly optimistic there is a way to solve it outside of "don't give as much equity since nobody wants it", but I like to think there are smarter folks out there who can come up with something.

I think most people would like that, but options can be created out of thin air, while money cannot.

There are numerous tax pitfalls along the way were you can get absolutely ruined if you do it wrong. Exercising options can very easily become a non-trivial investment in actual cash.

None of these details are particularly predictable when you start out.

Ownership is ownership, but details matter. There is a long way between signing an options agreement and true ownership, liquid or otherwise. The longer that path, the less certain the payoff, and the less valuable the options.

That's a real problem for people trying to start a company without a lot of cash. If it's to be useful as compensation, equity should be valuable, but it's not because the payout is so uncertain and so far away. Throw in terms that leave multiple opportunities to kiss the whole payoff goodbye just because of life (or worse yet, get screwed over by the IRS), and it's no wonder employees don't particularly value equity.

Typical option agreements are not terribly effective, so you may as well just pay cash unless there is a better way to distribute ownership in today's environment.

It's not a simple problem to solve. Saying "give more equity" doesn't really do it if the problem is that the likelihood of seeing a payout is too small. And making the payout more certain is not easy.

Incidentally, it is WAY easier to cancel a Cox account in person at the local office than on the phone.

You could imagine a preferred offering with a 1x liquidation preference and some modest return, for example. The details really matter here.

I haven't really kept up on it since, but I believe it's still running a humble 486. Granted, the rest of the machine isn't much like my old Dell, but I always found that interesting.