NDC Oslo 2013, day #2


It was busy day. Very busy. Information overload!

This time, it’s be very fact-based, just programming stuff.

RequireJS

It helps to solve the following problems:

  • Developers needs to ensure that all dependency JS files are loaded in the correct order => it results in a dependency map, hard to handle, manange, etc.
  • Only god knows what’s the dependency map of the single-page apps (SPA)

 

Solution:

  • use RequireJS

 

How to start?

  • just import <script data-main=”js/main.js” src=”require.js” />

 

It’s AMD complaint (asynchronous module definition)

=> AMD is aimed to solve dependecies and modularity of the application

 

 

Module pattern

  • Helps separating public/private members, establish scoping
  • There is revealing module pattern which is better (more readable) than just standard module pattern.

 

How to define a module

  • Use define() method
  • Syntax: Define(id?, dependecies?, factoryMethod)

 

 

It’s possible to define a module with multiple dependencies:

  • multiple dependencies, but you need to follow the order of dependencies

 

Using a module

  • Using require([dependencies], callbackFunction)

 

Configuration:

 

 

Advantages:

  • It’s non-blocking asynchronous loading mechanism
  • automatic dependency map resolution

 

AMD vs CommonJS

  • The difference is asynchronous vs. synchronous loading
  • CommonJS for server side, see node.js
  • Instead of define() method there is export
  • You can mix them on the server side
  • CommonJS doesn’t make send on client-side because we don’t want synchronouse loading

 

Possible to use it for loading not just JS but other files, too. Works via plugins:

  • Plugins for loading text files, css, json, etc…
  • Other useful plugins:  async, domReady, etc.

 

This approach can result in sending many requests to the server

=> use optimizer to bundle it together, it’s page specific, works as node.js package

 

Testing

  • 2 purposes:
    • Loading dependencies
    • Overwriting loaded dependencies for so called mocking, works well with BDD/TDD style (I’ll write a blog post just about testing with RequireJS)

 

Future

  • RJs is just a middle step
  • ES6 module, export, import capabilities is going to be replacement, let’s see what comes

 

 

Summary

IMHO, TypeScript is a way to go.

  •  It can compile TS code into JS and use AMD (via RequireJS) for resolving dependencies and
  • once browsers support ES6 (hope next year), the TS compiler will just use new capabilities, no changes on development side

 


Maintainable CSS

talk about how to organize the CSS in the maintainable  way. See slides attached.

Takeaways:

  • Use SASS (already using ;o)
  • Look at the Compass which provides SASS plugins
  • Follow object oriented style of CSS
  • Use BlockElementModifier style of writing the CSS style names
  • Take a look at:  Scalable and Modular Architecture for CSS

 

It’s great to see our front-end guys following much of that style which really turns CSS into maintainable piece of code

Unfortunately, not very good talk.

 


Telephones and postcards: our brave new world of messaging

This was performed by Jimmy Boggard. I met his output when using StructureMap, anyway, respect!

Nice talk, I bet you to see online video next week. Main takeaway was how he presented CQRS system on real-world example (ala burger king shop). I like this style when the speaker use real-world examples explaining the technical stuff. If you want to use CQRS (I bet you should know about it), watch the video!

 

 


 

Erlang: a jump-start for .NET developers 

I must say great talk. Great to know about Erlang, its approach. Deails can be found here

 Takeaways:

  • functional language which can achieve 99.9999% of availability
  • complements C# as any functional language
  • concurrency oriented language, fits really very well for solving concurrency problems with fault tolerance
  • Main idea about concurrency:
    • Concurrency via message passing is faster, scalable and cheaper 
    • Shared memory concurrency is hard 
  • Difference to traditional styles:
    • 1 thread in WinOS allocates by default 1MB
    • 1 thread in Erlang just 1 kB => results in less overhead, bigger throughput
    • and many more … 

 

It’s main goal is: concurrency and fault tolerence

  • Worth looking at the video or at http://erlang.org

 

Already used by many known companies in the production!, i.e. Facebook

Btw, Erlang concurrency model reminds me new OS, currently in the development phase, Midori.

 


The Architecture of Uncertainty

Again, general talk, worth watching the video.

Takeaway:

  • isolate uncertainity from your system by making a border (interface) so that the code is not affected when uncertainty evolves. 

 

 


ClojureScript: Lisp’s Revenge

Funny message was announced by the presenter: JS is dead ;), closure will survive 😉

 Takeaways:

  • Based on LISP
  • Solves JS pitfalls
  • Compiles to JS
  • Has module support
  • Immutable lists
  • Better scoping
  • Equality is based on the value
  • Uniform interfaces
  • Lazy sequences,
As it’s know, it’s good to know this language because it can help to solve i.e. pattern-matching-based issues in very elegant, clean and short way. I had a talk during party with the closurists and it’s really different approach, but interesting.

 

Uff, that’s all for now… yeah, party time  .. 

MaintainableCSS.pdf

Comments (0)

Skip to main content