| class UIView | |
| def controller | |
| controller_for_view(self) | |
| end | |
| def controller_for_view(view) | |
| controller = UIViewController.viewControllerForView view | |
| if controller | |
| controller | |
| elsif view.superview |
| # Copy ActiveSupport::Inflector.underscore to convert CamelCase angular controller names to snake_case controller spec names | |
| class String | |
| def underscore | |
| self.gsub(/::/, '/'). | |
| gsub(/([A-Z]+)([A-Z][a-z])/,'\1_\2'). | |
| gsub(/([a-z\d])([A-Z])/,'\1_\2'). | |
| tr("-", "_"). | |
| downcase | |
| end | |
| end |
Most non-trivial apps need to deal with user authentication. In this post, I'll walk through how to implement user auth in an AngularJS application and how to account for some complex scenarios that might arise.
###Step 0 - Create auth file
I find it useful to put all this code in one place, so I've created a file called auth.js.coffee in my /angular/services directory.
auth = angular.module "genericapp.auth"
| Preface | |
| "They're writing legacy code" - from a consultant working with a new team | |
| Fixing legacy code is like surgery: first make things better and then use that as a catalyst for change. | |
| This book is not about clean code and not about good design | |
| Question: I'm curious to see if knowledge of how you would architect the system now, from scratch is necessary or helpful in going about refactoring it. Do these techniques need you to have an endpoint in mind? | |
| Chapter 1 | |
| It doesn't matter if you are adding a feature or fixing a bug, you are solving a problem. |
It took me a long time to warm up to pull requests. My early experiences with code review were all a tremendous waste of time: they were a bottleneck to getting things done, a forum for people to conduct their ongoing feuds or both. After years of being staunchly against pull requests, I've come around on them in the last year at Terrible Labs.
Start with cthe big picture and get more detailed from there.
My pull request should be trying to accomplish only one thing and that should be explained in enough detail in the commit message for you to understand, did I succeed? If something is confusing: you're not sure how this system works, or how this new piece of code fits in with other parts of the system, let me know and we can clarify it together.
| When you're a beginning, its hard to elaborate what you're learning because everything is new and what you're learning is everything. You're learning about each individual piece, how they fit together and where you fit in. |
Today marks a major change in the direction of our project. We're switching from jQuery to Tinder for all date picking across our platform, effective immediately.
Making such a large change wasn't an easy descision. It means learning all new APIs and rewriting dozens of lines of code and possibly even some tests. We are almost certainly the largest standalone application to make this decision but this kind of bold decision making is exactly what got us to the top and its exactly what we need to keep us there.
We started using the jQuery Datepicker back in 2005. It was a different time, we were a small upstart company doing whatever it took to make a name for ourselves no matter how many friends we'd lose or companies we're leave dead and bloodied along the way, just so long as we could make a name for ourselves in the industry. jQuery Datepicker was the hot new technology on the block and it was exactly the kind of bleeding edge technology that we needed to disrupt our entrenched competition. The first few
| /* | |
| * robotMaze.js | |
| * | |
| * The blue key is inside a labyrinth, and extracting | |
| * it will not be easy. | |
| * | |
| * It's a good thing that you're a AI expert, or | |
| * we would have to leave empty-handed. | |
| */ |
We didn't lie to you, but we weren't completely honest either. Its just a lot easier to pick one way to do things and stick to it than it is to explain all of the possible approaches with their tradeoffs.
You're starting your second job now and its going to be one of the most interesting times in your career. Its when you discover that there truly are an infinite number of ways to accomplish the same task. You'll probably find out that you have a pretty good handle on what to do, but not necessarily why you ought to do it that way.
Don't be too dogmatic. This is a tremendous opportunity to learn, both about new ways of doing things and also about the strengths and weaknesses of the approaches that you've been using. When you find yourself thinking "OMG, what the hell is this?", pause for a moment and try to figure out what the tradeoffs are: what could be some advantages to doing it this way? And ask a lot questions: "I see that you're using [tool A] instead of [tool B], why is that?" Maybe they'll have a g
| Step 1: Board | |
| 2D array 5x5 | |
| value of each entry is a letter | |
| Step 2: create game | |
| initially randomize each letter | |
| this will probably need to get more complicated later (like redo unless vowels > 3 or something) | |
| game board is immutable | |
| Step 3: Game State |