| Long technical texts in English |
| 1 | Directives are awesome and powerful I'm of the opinion now that Directives are the killer feature of AngularJS. They are wonderful little packages of contained UIPresentation logic. They present so much flexibility and power with their ability to extend the grammar of HTML. We definitely use directives, but perhaps not as much as we could. One of my favorite aspects of Angular Directives is that they are composable. Using them as HTML attributes, we are able to leverage directives to build complex widgets with layered functionality. This can be a double-edge sword at times, when the layered functionality wants to compete, but overall it is awesome. If I was starting a project today, I would put some serious thought into organizing Directives as visual components and behaviors. There are already several projects that wrap popular UI frameworks with Angular Directives, but it isn't strictly necessary to use a full-blown component set to approach it with this mentality. What are the primary components of the application? How can it be built around directives so that the primary components are shared throughout the application instead of cut-n-paste HTML and CSS sprinkled everywhere. How can I leverage these components for future work? If you haven't watched them yet, bounce on over to John Lindquist's egghead.io and check out the series on Directives. All of the videos are excellent, but the Directives information is enlightening. |
| 2 | This isn't related to Angular directly, but is another important aspect of your AngularJS project so I wanted to spend a little time on it. I will admit that a year ago my attitude was "f css". It confused and frustrated me to the point of distaste. Obviously this stemmed from ignorance, and I've spent the last year trying to play makeup with CSS. My attitude is no longer "f css" and sounds more like "SCSS!" because I found a happy place where CSS and I can get along. SCSS syntax takes many of the pain points that put the screws to my brain with vanilla CSS and added a nice level of clarity. On top of that, Compass provides a pile of wicked mixins that eliminate an entirely new level of pain from the stylesheet workflow. In the future I want to dig into SASS Compass deeper, combining its expressive styling capabilities with the module and component level AngularJS work outlined above. I'd like to use a more organized approach to my stylesheets with something like SMACSS providing a baseline standard for how the styling is implemented and organized. At this point, CSS and I have fully made up. I've removed a lot of my ignorance, which was obviously the key to building a solid relationship. We will see how it goes. One day at a time. |
| 3 | As we ask our client-side code to take on more and more responsibilities—indeed, whole applications are living largely in the browser these days—two things are becoming clear. One, we can't just point and click our way through testing that things are working as we expect; automated tests are key to having confidence in our code. Two, we're probably going to have to change how we write our code in order to make it possible to write tests. Really, we need to change how we code? Yes—because even if we know that automated tests are a good thing, most of us are probably only able to write integration tests right now. Integration tests are valuable because they focus on how the pieces of an application work together, but what they don't do is tell us whether individual units of functionality are behaving as expected. That's where unit testing comes in. And we'll have a very hard time writing unit tests until we start writing testable JavaScript. |
| 4 | Scalability It all started when a bunch of eBay engineers (Steven, Venkat, and Senthil) wanted to bring an eBay Hackathon-winning project called "Talk" to production. When we found that Java did not seem to fit the project requirements (no offense), we began exploring the world of Node.js. Today, we have a full Node.js production stack ready to rock. We had two primary requirements for the project. First was to make the application as real time as possible–i.e., maintain live connections with the server. Second was to orchestrate a huge number of eBay-specific services that display information on the page–i.e., handle IO-bound operations. We started with the basic Java infrastructure, but it consumed many more resources than expected, raising questions about scalability for production. These concerns led us to build a new mid-tier orchestrator from scratch, and Node.js seemed to be a perfect fit. |
Комментарии