You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
lightweight, not opinionated. opposite of rails. not a lot of established patterns.
ruby programmers in general not good at javascript.
notes and slides published.
a lot of the backbone docs are written for javascript people, not rails people. a lot of people starting out don't have the context they need.
talked about building a webapp that as no markup, calls API's - 'Greenfield App'
since backbone has no opinion on where code should go, code debt can come quickly
experienced javascript programmers don't have the problem.
-backbone makes it easy to incrementally change from regular app to a greenfield app.
-backbone requires writing a bunch of boilerplate code
-starting a new project, might look at a newer framework. emberjs?
-javascript frameworks are coming up that are more opinionated, which has the benefits of rails.
Questions:
in heavy javascript app, does javascript still feel like a second class citizen? she spends a lot of time in app / assets.
natural for rails people to focus on rails stuff.
as a community we are moving towards js being a first class citizen
concern about moving to javascript: as moving code from ruby to javascript lose control over how the code gets run. browser compatibility, how it runs, etc.
is a problem. supporting from ie6-ipad.
once building a few apps, know where problems come
most clients dropped ie6, ie7 support (applause)
I think the most interesting part of the talk was how many people were here. Room was packed.
REST, a lot of people didn't think it was improvement; before you didn't need a routes file. While it's an imrpovement
Ruby 1.9 - is this really needed people think? Pain in the ass to upgrade
Bundler - dhh thought it was good from the begining. Lot of haters though
A lot of people don't think theat Rails 3 is progress.
How many people are using Rails 2 in production (about 1/5th).
Why do we need Rails 3? Rails 2 was fine.
Asset Pipeline - people already had a system of 5 gems?
Rails keeps innovating, even despite the fact that a lot of people are hesitant to change.
Do we like progress?
-most people say yes
-when it impacts your work, it's harder to change work
-CoffeeScript - if there's one piece of progress that was a lot of feedback.
-foreign
-un-natural
-used to semicolons are good.
-Common theme: 'The old one was better'.
"I too get mad about progress. They change the way a touchpad works, it's like why did they do that."
Not all foreign concepts are progress
-Wonderful thing about software development - we can measure these steps forward in a somewhat objective manner
-clearly measurable progress
-Person.find(:conditions => {:name => 'David'})
-Person.where(name: 'David)
-This is clearly better, easier to type
-Skepticism is OK
-Default Mode of Curious about new things -> Default Mode of Suspicious
-bad approach.
-gradual change
-Analyze when and why does the switch happen? Not a good switch. Not good for community. Not good for progress.
-two theories on why
-a conservative is a liberal who got mugged.
-most people start by being curious. they started the techology because curious
-everyone likes the cutting edge until they cut themselves
-lost data / introduced a bug / upgrading took longer than expected. people are now like aww fuck need to upgrade again.
-then this guy starts yelling at you. customer or boss said 'what the fuck, system was fine. works fine. if it aint broke don't fix it.
-mental process becomes "This can never happen again"
-reaction to a bad incident. like bad shrimp. you hav one bad experience, next time you see it will make you feel like i feel about scrambled eggs after the airport yesterday (f that noise)
- causes an overreasion. need to stop this from ever happening again. we tried progress. it didn't work.
- indulge in overreaction. waste time on the wrong things. if you're going to change it on your own, you're going to introduce your own damn bugs
- progress is bad because lost data / etc / boss yelling.
- this is the kinder reason to why people are resistent to progress
- i don't think it's good that rejecting progress for fear is good, but we have something to point to
other reason is much more incidious, harder
getting old!!!!
it is a function of getting old that you don't like change
not old as in age. this is about the mental pattern that happens in your brain that turns your brain old in the way of thinking
when young, change is easy. go ahead put a bandana on your head, move to the mountains. no consequences. lovely. perfect curious state.
opensource community like this hippyness. free love. free code.
most people don't stay in this state to the end of days
old hippies are rare (stahlman)
most hippies turn into this guy. mr. mature got good things out his initial curiousity. path led to good things. house, yard, dog, volvo.
mr mature has something to lose. if you're a software developer and you're mr mature, you're invested.
don't try to tell me how things are and how things are going to be.
downside of being a good thing. tons of people using, tons of usage.
when have nice things, instinctively nervous of losing them.
this fear will slowly suck all the fun out of you.
completely curious hippy to complete mr mature takes 30 years
in tech, we don't have that much time
takes 3 maybe 5 years to change mentality.
people can move into mr mature overnight
curious -> suspicious , hard to go back
mr mature "I'm going to sell my house, shoot my drive, and push my volvo off a cliff and start playing my hippy guitar"
best thing to do is postpone.
tramatic event that causes to overreact
loss aversion is the pillar of conservatism (mental frame of mind, not political).
conservative because don't want to lose things.
nice things are nice to have
what i don't like is the bullshit we weave around it.
"I have nice shit, so don't fucking change anything, alright?" - i respect that. honest.
what i don't respect. people looking back at hippystuff as a bad ting.
bill clinton, marijuanna quote. "that's not true. did inhale, but mr mature now"
trying to lie to himself, and other people
not as harmful as the other natural path people take when they can't come to terms that they have nice shit and don't want to lose it
need another justification for mode of being.
talking about public policy, and things that should'nt be allow. they have to bring the fucking kids into it. progress is bad because of the children
progress is bad because of the noobs
"All this progress is overwhelming to the newbies. Their brains can't handle it. Need to come up with a safer world. Don't make them cut their hands on the cutting edge).
that thinking is how you end up with the easybake oven. (easy back commercial).
technology -> easy back. easy fun to learn. easy to learn.
have you ever eaten something from the easy bake? fucking discusting.
my wife wanted the easybake for 3 years. mom kept saying fuck no. there was a reason. they had an over. she could make real cookies that are delicious
real over is dangerous.
by the time she was 11 she could make real cookies.
need to treat newbies the same
progress can be hard and frustrating
learning valuable life skills and can use and actually use
don't teach people how to cook crap cakes.
if you want to learn real skills, need to learn to bake in real over. use a real framework that will solve real problems. move we progress harder it will be. more stuff we add, more stuff to learn. that's just how it is
dummies incisious allies.
mr mature has all this knowledge. this is hard stuff. this took a long time. you can't just learn this stuff and be just like me.
keep it at your level.
also have mr dummy. just starting to learn. not confident. i'm a dummy, treat me like a 5 year old
"Fuck this fuck, mr dummy." Incidious alliance with mr mature, treating people like 5 years.
don't be like we cant use big works.
"There's no speed limit to learning"
huge amount of progress he could make. this progress was suposed to take a year. if people set high expectations, it's a natural human instanct to live up to it. if you set expectations for mr dummy. not a great way to learn anything. not at a great race.
I built rails to quickly, because there was no speed limit. No one was like: "first you must learn ruby, then you can build rails".
people voluntarily adopt this role of mr dummy, and people are eager to refer to him in that role.
loss aversion - people hate losing vs like gaining. context of mr mature.
"You do not need to be stuck into being loss averse. You can fight it"
when priming people, less loss averse. more reasonable manner. embrace what comes with that.
we can hack our brains.
I'm not no dummy, I just don't know yet. But I will learn. And I will be awesome. Should absolutely be able to embrace that in the learning phase. You can learn this stuff much faster than you think. Don't need to easy bake. start with the real stuff
if you are mr mature - don't need to be suspicious. can't be curious
be a pioneer. refocus, reframe mind.
the only great products i know are made by people who use them.
i can't make a great easy bake oven, because i don't give a shit about easy bake over.
use this to how you think. don't produce shit nobody will use. mostly only time you can build software they personally use because they care. otherwise they would need to be paid.
Progress is painful - it hurts less if you accept that.
Rails 4 will change this. Rails 4 will break things. It will hurt.
"I will not fear change / I will not fight progress"
Overall the big theme of the conference among the keynotes was about self-awareness about the community, where it was going, and why it was on the path it was. Also some discussion on whether the path is good or not.
All quotes are paraphrases. Not word for word quotes.
Keynote: Progress Is Hard
dhh
Burn down your house, shoot your dog and push your volvo off a cliff.
If you ask most people if they like progress they will say yes. This is typically a lie though. Bundler is awesome, had a lot of haters though. Many people don't think there was a need for Rails3, Rails2 was fine.
The old way was better.
People tend to have two modes of approaching something new. Curiousity, and openness, or skepticism and doubt. When people came into the rails community they almost always came in with curiousity in openness. Yet over time this curiousity changed to skepticism. This change isn't good for the community or the progress of it.
Why did this change happen?
Two theories:
A conservative is a liberal who got mugged. Everyone likes the cutting edge until they cut themselves. Being on the cutting edge can cause data loss / introducing bugs / taking longer than expected. This is typically not interesting to managers. When these bugs happen they'd ask "why did you do that, the old system was fine?"
Aversion to things like this causes people to be resistant to this change, and over-reaction.
This is the kinder of the two theories.
I don't think rejecting progress for fear is a good thing, but at least it's something to point at.
The other reason is Programmers are getting old! Not as in age, but in the mental patterns that they use to model the world.
When you're young change is easy. Put a bandana on your head, move out to the mountains. No consequences. Lovely. Perfectly cutrious state.
Opensource community is like this. Free code. Free love.
When was the last time you saw an old hippy? They're rare. But they do exist (Stahlman).
Hippies don't usually turn into this guy though. They turn into Mr. Mature. Mr. Mature got what he has from his initial curiousity. This is the path that led to good things. A house, a dog, a volvo. Mr. Mature is invested. He has something to lose. It's a downside of having too much of a good thing. There is a fear of losing it.
Real hippies take 30 years to do this transformation. In programming it takes only 3-5 years. Moving from curious to suspicious is an easy path to take. Moving from suspicious to curious is harder to move back from.
Nice things are nice to have. I understand that. What I don't like is the bullshit that gets weaved around it.
I have nice things so don't fucking change anything alright? I don't agree with the mentality but I respect the honesty.
It's like Bill Clinton saying he didn't inhale. That's bullshit, we all know he did. And it was fine when he was a hippy and it didn't matter, but now that it doesn't fit with Mr. Mature he's lying to other people. Maybe even himself.
When people are trying to justify the truth why do they always have to bring the fucking kids into it?. Progress is bad for the children… or in our case the newbies.
All this progress is overwhelming to the newbies. Their brains can't handle it. Need to come up with a safer world. Don't make them cut their hands on the cutting edge.
That mentality is how we got the easy bake oven. You ever eaten a cupcake out of an easy bake oven? It takes like crap. My wife wasn't allowed an easy bake oven when she was a kid. She wanted one, but her folks forbid it. You know why? Because they had a fucking oven.
A real oven is dangerous though. You can burn yourself on it. It's also harder to use.
But by the time she was 10 or 11 she could make delicious cupcakes while her friends were cooking garbage in an easy bake oven. She learned a real skill that mattered.
If you want to learn real skills, you need to use the real tools for the job.
Mr. Mature has all these skills. They're hard to learn. Took five years. You can't be as good as him. Or that's what he wants you to believe.
Mr. Dummy is the incidious ally of Mr. Mature. Don't act like we can't use big words or do something right. I'm not a dummy, I just haven't learned yet. You can learn this stuff faster than you think. You don't need an easy bake oven. You need to start with the real stuff.
Progress is painful. It hurts. Rails4 will hurt. It will cause bugs. It will take time to upgrade.
I will not fear change, I will not fight progress.
Stay young. Stay curious. Stay hippy.
Backbone JO
Sarah Mei (pivital labs)
A lot of the presentation was about why would want to use backbone, and also there were some code examples. I wasn't paying too close attention to the code examples.
lightweight, unopinionated. because of the lack of conventions, code debt can build up quickly.
backbone requires a bunch of boilerplate code
starting a new app, she would probably look into using embder.
The room was packed. I think a lot of the rails community is interested in javascript, and see the importance of it. Were some other interested talks going on at the same time.
JOSpacial Analysis with Rails
Daniel Azuma
This was actually a really solid talk. Should review the samples and slides here. Most solid non-keynote presentation I went to.
When dealing with geo data using a geo database is key. PostGIS is the best solution for geo-spacial data.
The presentation went through building a couple of projects. Talking about all the code required.
Project 1 - like around me now. Visualize a bunch of points on a Google Map.
Storing lat and lng in a normal database as a decimal is like storing a timestamp as a string in the database. You can do it, but you'll lose a lot of querying power.
Since this project wants to use rectangular bounding boxes, it is easiest to store the data in the database as a mercator projection. This metric willmake querying for a rectangle easy. Storing it as lat/lng would make it so a seemingly rectangle of coordinates would actually be a pie shape.
Also Google Maps uses a subset of the mercator projection for points, so using this metric would be easy for mapping with Google Maps.
The project was built, and did the job but there were a bunch of points on the google map. It was flooded and unreadable. Daniel built a javascript plugin that adds a heatmap to a google map. On github. The ultimately right way would be to store the rasterized rectangles in the database, and then render from that.
Project 2 - given a location find the timezone.
Interesting problem, since we needed to solve it before. Also stored data as mercator projection.
The geo data for timezones are available as shape files online. Download these, and import them into the database. PostGIS supports polygons.
PostGIS can't optimize for distance query, but can do overlap easily. After we wrote code that was based off distance, we switched it to build a polygon of a circle and checking for overlap in that.
Common optimization is to use 4 to 1 breaking down of polygon. Otherwise the tables would be very fat with columns for each point in the polygon. Running simulations of code with different width tables allows determining what the optimal value is.
####Questions
When do you use mercator projection vs lat / lng?
It's sort of a case by case basis. When I first started I used to dump everything into lat / lng. As you deal with geo data you'll see the hard parts to optimize, and learn when to use each. There are tradeoffs for each. The more you do it the easier it is.
Improving Development through Operations
Speaker worked for a tee shirt printing company.
Mostly sys admin discussion. Their deploy process is actually pretty solid, but it would never fly at WHERE because systems won't let us deploy no matter how many times we tell him we should be able to. I think it might make sense to raise this issue again.
Talked about how they went from having frequent rollbacks on deploys to almost always smooth deploys by doing a lot of them.
Tools:
CapHub. Open source. Just like swallow, but more flexible.
Vagrant. With chef allows developers to spin up production instances on a local vm to debug issues.
Greenscreen. On their company's github page. Cool visualization on if the build is broken. Much like Ian's face, but less fun.
A bunch of questions. People seemed genuinely interested in the topic. I think most of the developers were a little unfamiliar with chef, so there were a lot of specific questions about how to use chef and optimize chef.
ActiveSupport Hacks
This was all about ActiveSupport notifications. This talk can be condensed into the following statement that he made at the end:
After the talk search the rails code and search for the word instrument and see how it works in actions.
Kind of a waste of time.
Making the Internet Faster - tricks from the trenches @ Google
Illya Grinko
Was expecting tips on how to make apps faster, but was really all about how to get metrics about what things take the longest. Notes.
While you might think making your website faster you should tackle that slow sql query or gross slow code, you will probably be able to get a much bigger improvement from a user perspective by tackling a completely different class of problems.
Measure Everything!
There is a large team at Google who has the goal making the internet faster. Not just google properties all the internet. They are judged on how that have made the internet as a whole faster.
In Google Chrome, in javascript console type performance to see interesting metrics about loading time for all sorts of different metrics. How long did DNS take to resolve? How long did it take to click the button to get the last asset loaded? It's all there. Type performance.
Histograph Everything
Google Analytics can track advanced performance of pages by
Chrome Dev Tool exposes a JSON ended point as a json API on local host. Can get interesting metrics from it. Especially interesting for things that do long polling.
webpagetest.org, allow graphing of results from different locations, in different browsers. Also a video of how users will see the page.
Speed Index, measures how long it takes for the page to be able to interacted with (not full data).
Google PageSpeed Online. Punch in URL, and give recccomendations.
mod_pagespeed - Apache Plugin that automatically alters page to have best properties to be fastest
PageSpeed Service - point dns to cname, and will automatically process
Keynote: Failure
tenderlove
I've made a huge mistake
-Gob Bluth
Pretty good presentation. Ended very abruptly. I thought he was joking when he ended. I think he might've gotten shafted on time because there was some other guy talking before him so he started late, and there was stuff happening immediately after. Kind of sucks.
Talked about the importance of wycat's binary installer for osx. Talked about why it will be hard. Will require native extensions that get compiled get a special version. This will take a lot of leg work and is not an easy initiative.
ActiveQueue - nobody uses it.
Has no documentation.
No examples.
Lots of configuration.
0 Lines of Code.
Things like: resque, rabbitmq, activesupport queue don't have a common interface. To change to use a different implementation you need to change underlying code. Sucks.
New Developers are more likely to click the merge button
Three different types of commits exist.
Cosmetic Changes - dubious value and unknown debt. Support for logger namespace is an example. There was a feature that would allow code like this, return the following output.
Rails.logger.namespace "omg" do
Rails.logger.info "Yeah!"
end
[omg] Yeah!
This was added in one pull request. Didn't work across threads properly. Had some bugs. It was possible for logger lines to look like this:
[why] [do] [we] [need] [tis]]
Ultimately took 10 pull requests, and even more contributors. This is a change that had dubious value, and a lot of debt.
Refactoring Changes - high value and low debt. Notifications are an example of this. By changing the implementation from 500+ lines of code to under 200 lines of code, and making it simpler a new feature was added to the language.
Course Correcting Changes - high value, unknown debt. Asset pipeline was an example of this. Rails saw that this was a major problem that many people were having. They knew it was the right thing to start trying to fix this problem. Willing to take on high risk to make this happen.
Asset pipeline was a change that was too big to fail. The rails community needed to make it work in order to ship the product. It was a lot of work, and had a lot of bugs. It also wasn't exactly the right thing. It was a step in the right direction, but there were problems.
Changing of where processing is done
Initially there were mainframes dumb terminals. This ultimately changed to software that users would install on their machines. After this the web came out and code was being centralized back onto a single machine. Now we see javascript, and code is being run on the client again.
Then it abruptly ended
Keynote: Simplicity
the guy who made clojure
There is a difference between easy and simple. Easy means something that is close at hand. It's easy to install a package using apt-get. Simple refers to making things work in a straight forward manner, and not complicated, or interleaving different things together.
Complect this is the verb to make something more complicated. Next time you come back from vacation and code is spagetti ask 'why did you guys complect the code base?'.
As programmers we place too much importance on our experience (easyness), and not the similicity of the product. Simplicity allows cool things in the future.
Don't return a domain object with data if you just want to convey data.
Always use maps.
The rest of the talk was talking about benefits of keeping things simple.
Keynote: Developers and Startups
david cohen. ceo of techstars
Has a book, gave away a few copies of it. Most of these tips I believe are in the techstars book. Seemed like a down to earth guy with a lot of practical knowledge. I should look into getting and reading the book.
People starting out for the first time need mentors. A person without mentors had a startup. It was successful got acquired. Afterwards they talked, and they realized they left over half the money on the table. Experienced people who have done it before will be able to help you.
Avoid Tunnelvision. This is advice from Bijan in Boston. Tunnelvision happens when you assume you are on the correct path, and just continue going down it. It never hurts to assume you are wrong, and assume there is a better way.
VC's value a good team over a good idea. Most people who go into techstars come out with a radically different idea when they exit. This is because they are flexible, and not tunnelvision entrepreneurs. Someone asked if techstars would bring in a team without an idea. He stressed the importance of a team, but also that you need to have an idea to get in.
Asked how many people were currently hiring. More people had hands up than had their hands down. There were 1K+ people looking for Rails developers.
Developers are the new investors. Developers are resources that are currently choosing what companies are successful and have a chance. A company can have all the funding in the world, but if they can't attract talent, they won't be that successful.
A lot of different mobile devices provide a completely different interface to the current apis. Things like orientation callbacks are a total grab bag. Some fire the event before the orientation changes, some afterward. Everything is different.
Web Applications that are in the context of a regular app from a web view behave differently that web apps in the context of a mobile browser. Different performance, memory, ec.
Andriod is the new IE
Android is the quirkiest mobile browser ever. They implement a lot of features, but will implement them broken. This is worse than not supporting them at all, because that means calling the javascript function the determines if a feature is supported will return true, but it won't behave correctly. Microsoft on the otherhand doesn't support a lot of features, but when it does they work correctly.
Even rendering is jenky. Things like rounded corners looks shotty.
Bizzarre form bugs. Putting an absolute element, inside an absolute element, and then putting a form inside that will make forms not submit.
Tranformations work on toy examples, but when any real amount of data is needed the performance is so bad.
How JQuery Mobile Works
Back button support took a lot of work. They went out of their way to make it work. Talked about technical details about how to make it work properly.
data-cache=true // this is required to make back button work, also need to use unique links. link helpers in rails can make this happen.
Alert debuging is retarded, finally have good mobile debuging tools. Can connect chrome debugger to android.
firehose.io
This is fucking sweet. Go to firehose.io and do the demo. This makes it insanely easy to make insanely realtime apps. There is a third party app that runs and does most of the hard work, and it uses RabbitMQ.
For when long polling (setting a timeout and making a new request every 10 seconds) isn't good enough.
Why do other tools suck?
Long polling has problems. When one error comes up, it will cause you to get bombarded with stacktraces. Airbrake emails that gone over threshold happen all the time when long polling and a bug is released. Also has more stuff going over the wire. Making many requests. Also not realtime.
Socket.io has some problems too. There are not really TCP over HTTP. Making it work like this to add features is a neat concept, but it has a ton of problems.
Meteor is very promising but also has problems. It tightly couples the server side logic with the client side logic.
Revisiting the Problem
Instead of thinking about logically what tools currently exist that would be neat to work over http, rethink the problem. What are they actually trying to solve:
Right now it sucks to push data from the server to the client over http
We don't need to emulate sockets to make this work.
Any web protocol that you can't interact with, with curl is too complicated. Should be simpler.
Firehose.io is a thin server, with rabbitmq. How he sets it up is on a completely different machine, so even if realtime stuff breaks, the rest of the site will work.
stream.whatevercompany.com/[what key are you subscribing to]
SASS Presentation
Me and Pete snuck into the last 10 minutes of the SASS talk because a different presentation finished early. Turns out they just rewrote sass in c. libsass is now available, and should make it more accessible to non-ruby environments.
This was the big announcement.
Why do we like Rails and why are people starting to doubt it?
wycats
This was one of the most solid presentations of the event.
Why do we like Rails? What does it give us?
We like Rails because it's convention over configuration. This eliminates the need for the programmer to make trivial choices. Trivial choices are bad, and consistency is important.
The more common the problem, the less decisions should be needed to make in the solution.
Talked about CSRF. How many people know how to make rails do CSRF? Most people raised their hands. Now if you were using sinatra and you had to build CSRF yourself, how many of you would actually do that? How many people would spend the time needed to make it work right? Talked about different implementations in different web frameworks. Django vs rails vs java.
When should you do a course correction into Rails?
When many people have the same problem.
There are many trivial parts to the problem.
There is benefit of shared solution
Learning all the details of the problem is hard.
Echo Chamber - people who know they should look for a plugin to solve their problem, already know enough about the problem.
Having multiple eyes on the project is important. Take the asset pipeline. That was around for years. There were bugs that went unfixed. Once it went into rails it got critical mass, and the problems got fixed since it was part of the framework
Consistency
ActiveRecord databases are different.
Initially there were a lot of trivial decisions that needed to be made when building a database. Use camelcase? Underscore? Plural? Singular? There is a win to not having to handcraft the solution. A DBA used to think about how the database should work. They would need to think about trivial bullshit. This isn't that important, and having conventions would be better.
ActiveResource + JSON APIs. Still inconsistent.
Building JSON is manual handcrafting. Include root in json? How do you include associations? Do you use the id? Nest the object? Backbone and Emberjs are different.
A lot of haters are talking about Rails now. People switching to stuff like sinatra. Part of the reason is, if we need to make these trivial choices, what's the point of using a framework?
Any Convention is better than no convention
It's better to pick a convention that isn't the best then spend a bunch of time discussing it, and picking apart trivial details. Lets just do it without the massive discussion.
There are common configuration things to serializing json and there are application specific things to it. Now when we serialize json we need to deal with both.
there is an activesupport serializing add on gem. This got merged into rails core, but some haters got it reverted. Should be in railscore though. The gem sounds very useful. Should check it out for serialization needs.
ember-rails gem makes ember work with rails json.
There should be a convention to how to do bulk updates. This is somehting that happens frequently enough to require a solution.
There's really no conventions over where to put javascript files. As rails developers we should lead the way and come up with convention that we want to use for how to organize javascript consistently. Need to be opinionated (unlike backbone.js)
Talked about using a process like Continuous Deployment, but manually running cap tasks.
Added visibility with Greenscreens.
Used Vagrant to setup production in a local vm
Lot of questions.
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
- If you hate maps, you'll probably hate them more.
- Authoed RGeo
- Chief Architect or Pirq - deals on
- More than placing pushpins on a Google Map
- PostGIS - this is the best solution for spacial data!
- Project 1 - like around me now. visualize a bunch.
- storing lat and lng as decimal in database are like storing timestamps as string. you can do it, but using the spacial data points, adds a lot of querying power
- NOTE storing in mercator projection makes rectanular bounding easy. Lat / Lng would make the bounding box not a rectangle. Using mercator projection allows this easily.
- Can use javascript, but gets slow on client side fast
- Use backend, store rastered blocks in datbase.
- Project 2 - location to timezone. polygons are available for this online, can throw this database and then using geo sql, determine where it is.
- postgis supports polygons.
- squeel allows you to write spacial syntax and hook into ARel.
- he pitched that this should be hooked into Rails4
- distances are related to the coordinate system.
- postgis doesn't optimize for distance (full stable scan), but does for overlap.
- to make it faster convert the radius into a circle object (actually polygon interpretation of circle) and then look for overlap.
- typically polygon data is stored in database, in width of the row
- common optimization, break multiside polygons into smaller one, use 4 to 1 subdivision
http://daniel-azuma.com/railsconf2012
Questions
---------
How do you determine which coordinate system to use? Really need some experience writing the queries about what queries to run. There are tradeoffs to each.
"When I started, I just dumped everything in as lat and lng. As I gained experience, I saw performance problems, I started investigating other problems"
When thinking about the first problem, since we were heading with google maps, coupling the database with the view of google maps makes a lot of sense, but there are tradeoffs.
In Chrome time 'performance' in console.
Google Analytics, has performance analytics, if you add a tag.
Step 2 - historgraph everything (also in google analytics)
Chrome dev tool, curl on localhost. Json. Can write scripts to parse it.
Remote debugging for andriod
No excuse, the tools are there. Chrome is the best tool you've ever developed for.
webpagetest.org, allow graphing of results from different locations, in different browsers.
Also a video of how users will see the page.
Speed Index, measures how long it takes for the page to be able to interacted with (not full data).
Google PageSpeed Online. Punch in URL, and give recccomendations.
mod_pagespeed - automatically does a lot of optimization from apache plugin.
PageSpeed Service - point dns to cname, and will automatically process.
Convention over Configuration - avoid the making of trivial choices.
More common problems require fewer decisions.
Talk about CSRF
"Can patch asset pipeline to use handlebar instead of erb"
Course Correction:
When to do?
-many people have the same problem
-many parts of the solution are trivial
-benefit in shared solution
-if learning about the problem is hard, there should be an automatic solution without understanding it
Failure to solve in Rails Core?
-critical mass. provide eyes, and hands, not a bunch of other solutions out there
echo chamber:
the people who will use a plugin, probably already understand the problem
not solving the problem for people transparency
ActiveRecord
"Databases are too different" camelcase / pluralized / etc. trivial choices no longer need to be made
in weighing the win of handcrafting solution
JSON APIS
no consistentformat. include root? associations? primary key? ember vs backbone differences.
Standardized Client Code. ActiveRecord standardized conventions. ActiveResource non standardized.
Now seen as 'not convention over configuration. whats the use of rails if i have to do it myself. why not use a smaller one like sinatra.
ActiveModel serializers.
What do serialize? How to serialize?
ApplicationSerializer class.
Any Convention is Better than no convention
don't need a massive discussion
don't talk too much, just do it.
Serializing avoids mixing common and uncommon. Opposite of rails without it. Convention / Configuration. Be able to change the configuration in one place.
EMBER-RAILS.
there should be a way to do bulk updates. common problem, no convention.
Need more convention for where to put javascript files.
