433 karma · joined March 27, 2007
There are other patterns you can use to track via version control the changes for your stored procedure.
At the end of the day, I would just use the tool that has the most comfortability with the team on the project. You can obviously start with an ORM, but there may come a point in time where performance needs a little boost.
Sorry for not explaining that fully.
SQL is rather readable these days. It's obviously not as easy to read as ruby or python and is slightly more verbose, but it is certainly readable.
Mileage will vary of course. There are cost/benefit trade offs with every architectural decision made.
We looked for some obvious optimizations like eager loading and some map reduce magic and implemented them. That brought us to a range of 45 minutes to 2 hours.
We decided that it was still not good enough. We moved ALL of the report into SQL functions (Postgres) and we have the whole function running in 27 seconds.
I agree with some of the top comments that maintaining this is a little trickier than ruby code, but some ideas we came up with in maintenance: 1) Write the SQL in a ruby file that has a class method of sorts that returns the generated function. This allows for version control to track the changes of the sql function. 2) Focus on tests at the interface level. We had great test coverage on the end result prior to moving to SQL. We were able to re utilize those tests to verify accuracy with calculations that are now in SQL.
This really isn't for everyone, but for those that want to try something new, it is worth it.
The only newsworthy item I have seen was this: http://mobile.reuters.com/article/idUSKBN12Y2WY
Of course nothing has come of this speculation, so it may end up being nothing.
My last $.02, given the sensitive nature of some of the information that Wikileaks releases, there is probably no avenue for corroborating the materials other than, maybe, how the source received said materials.
For those of you in either of these scenarios, recognize it and learn from it. Believe it or not, so much can be learned from good managers, but even more can be learned from bad managers.
Edit: My question is more along the lines of: Do you feel less loyal to the company or to the people within the company?
Small sample size for me (2 Ember projects, 6+ React projects), but the entry level engineers to the senior level engineers seem to grasp React/Redux MUCH faster than Ember.
There are providers that use JavaScript to allow you to take payment information on your platform but never let the sensitive details hit your server. I believe this removes your platform as an attack vector for leaking credentials. The only locations that have traces of that information are the browser and the payment provider.
Here is the thing I just dont get. Why doesnt some tech savvy organization create a white label solution that companies can either slap a subdomain on and invite "Customers" to fill ad supply. Self host the curated assets through said white label solution. Moderate with sophisticated computers that are not subject to the vast majority of mal ware (excluding 0-day obviously), and move on. Im sure someone could easily serve the ads off of the main domain anyway to circumvent all of the ad blockers on subdomains.
This is a perspective from the outside looking in, but people seem to just complain about the problem instead of looking for solutions.
EDIT: BAH, so there is a conversation from last year. https://news.ycombinator.com/item?id=10221859
Thanks for the post!
https://github.com/acdlite/flummox
https://facebook.github.io/flux/
https://github.com/reflux/refluxjs
https://github.com/reactjs/redux
Each of these appear popular in their own right. Given they mentioned Flux, it probably is the actual Flux library.
Maybe I should ask before stating: What was the intention of coupling your store and action in this scenario?
Le sigh.
Google fu yields http://stackoverflow.com/questions/17371334/how-is-attr-acce...
Depending on how your test suite is set up (if you have one) there may need to be some sweeping changes there. When we migrated we had to switch from our should syntax to the expect s syntax.
I can't remember anything else that was super crazy.
While speakers and talks were mostly on time, the rest of it was just pure chaos.