Nov 5, 2012

Exercising design

So many times we tend to complain about poor user experiences and badly designed interfaces. Some of us though are dogged enough to try their own take on these pitiful websites – to exercise their skills and because they hope that by doing that they may be able to be the drivers of change.

We've seen PayPal, LinkedIn, American Airlines and many others redesigned. There even was an answer to the latter one. Apple got such massive amount of negative feedback on iOS6 Maps app that Tim Cook personally apologised and suggested alternatives for the time being.

These few examples prove that despite training your skills sometimes you can actually make a difference. Try to start with small UI elements (let's say – one button set or widget per day) and go up to full redesigns of websites / apps which you always wanted to improve. It will make you the product designer, give you absolute power and liberate your creativity. Some companies already require self-started projects when hiring:

A portfolio that includes self-started personal projects for which you had total creative control. It could be an app, website, blog but it should be something where you were able to realize your vision.

If you're worried that some of these resources will "go to waste" try to focus on more reusable, functional elements which you can share on platforms such as Dribbble, Forrst or even Github. Open source and share your work – you would be surprised how many people could find it useful.

So go – exercise design.

Oct 18, 2012

NodeDublin

On Wednesday afternoon we've landed at Aerfort Bhaile Átha Cliath for NodeDublin — technically not first but for sure exteremely well organized node.js event in Europe. We've been envious of NodeConf for a long time and finally, thanks to Cian Ó Maidín we had a chance to see most of well known and widely respected developers from node community.

The event took place in amazing (and also very Irish) Guinness Storehouse. We kicked off with keynote by Isaac — a very interesting anthropological-oriented study on software (I strongly recommend reading the blog post about it). Second keynote was presented by Mikeal — who, as most of you already know, is an amazing speaker. After this rather inspirational, but yet node related introduction we dived deep into realtime and distributed systems. While demo gods weren't so nice for Substack we had extremely interesting talks by Dominic and Paolo.

Later on Max did a case study on Gather and Joe shared some insights about creating products in node based on his own experience. Couple talks later Day One was over and we all headed to The Sugar Club for one of the most interesting afterparties I've ever experienced — a whisky tasting with some intense bag piping.

The second kicked off with one of the most (if not the most) interesting slots — core node; with libuv, v8 and DTrace. Later on we've been introduced to Persona and got some DevOps advice from my colleague from Nodejitsu — Charlie McConnell.

After some light snacks Emily surprised everyone with really entertaining, rather smoky performance about Arduino. In no time the conference was closed by outstanding, inspirational performance by Jan and very interesting and persuasive talk by Rick Falkvinge. Right after that Cian quickly took the stage to thank all fellow organizers and sponsors. Felix also appeared for couple of minutes to show off a new event he started right before JSConf.eu — NodeCopter which gained a lot of visibility during last days (mostly due to its obvious awesomeness; robots!).

All in all, NodeDublin was maybe hectically organized but extremely successfull mid-sized conference. Dublin was also very welcoming (note that Irish cab drivers are probably the most cheerful and nice people on Earth). If you want to attend a node.js event in Europe — I wouldn't hesitate next year. Thanks Cian for putting this on.

Photos: by Matthew Bergman | by me

Notes, slides and trivia links from majority of talks can be found below.

Day one

Escaping captivity: Social Apes making Software in the Wild

presented by @izs | slides | blog format

  • We're here because we have technology in common. It's really the community these events are about though. Node is not a typical community.
  • The pattern will continue - future communities will act like Node community.
  • What are humans? We're most social creatures with most complicated social interactions.
  • Our story starts a little bit ago — last common pan/homo ancestor is dated for 5 million years ago. Evolutionary speaking it's very recent.
  • Anatomically modern humans are only 250,000 years old.
  • Hunt. Gather. Repeat. There's no room for ownership and selfishness, people need to share.
  • Agriculture pros: more calories, less moving around; population density (diseases); inheritance (hierarchical ruling class).
  • Hunter-Gatherer negs: one bad season can kill you all, babies die really often (susceptible to not getting enough nutrition), sorcerers can hex you (gotta kill them), might get caused of being a sorcerer (no legal system).
  • We started making shields and walls — you don't need these for hunting though. We started being offensive right about when we started farming.
  • Gombe, 1960 — chimpanzees were very friendly and they worked with each other.
  • Mahale, 1968 — very different type of animal. Chimps were tearing the boxes with food apart. They actually started setting up patrols around the camp. They became cannibalistic and very territorial.
  • When the food is one place, chimps don't get along.
  • Subsequent expeditions (to Gombe, Mahale) found that the changes were sticky, cultural. If you domesticate an animal and let it out to the wild it still stays domesticated up to some degree anyway.
  • Immediate return → Agricultural → Industrial → Information
  • Find it → Grow it → Use machines to make it
  • It order to have revolution it needs to be disruptive. It needs to be better, so the old things will be forgotten. Disruption sometimes causes terrible problems though.
  • Traditional model: programmers work for a company, company decides what to build, big apps, specs, process. Proprietary source, IP protection. Very little flexibility.
  • The more freedom you give your workers, the more they get done.
  • A lot of open source projects are managed by companies.
  • Open development. Open community. Open Innovation.
  • Node has the idea of relatively small core and noisy userland. It feels like we are wandering in the same wilderness together, trying to solve problems instead of fighting who gets blessed to implement something into the core.
  • Here Comes Everybody by Clay Shirky.
  • We explore with the greatest freedom we can possibly have to improve the community. We need to figure out how to share ideas without offending and bumping elbows.

Untitled

presented by @mikeal

  • Why is node successful? Is it successful? Fucking robots!
  • Nodecopter happened just before JSConf.eu. People were doing crazy things with parrot drones with libraries such as this or [that](Johhny 5.
  • The barrier of entry for working with hardware hasn't changed over the years so significantly. The boost of Internet enabled people who weren't technical to do computing and thus hardware hacking as well.
  • The callback pattern — function (err, result) {}
  • Streams — are for file descriptors, sockets; we're going to get or write data iteratively over time.
  • The substack pattern — module.exports = function () {}. So module should be so simple that it can be described by one function.
  • We have all these patterns which are being reused which makes us successful.
  • Logicomix
  • Solutions over problems. We need to be able to move forward. Somehow node.js is incompatible with modern institutions.

Intro to Streams Programming Patterns

by @mattpodwysocki

  • > McIllroy (1964) said: 'We should have some ways of connecting programs like garden hose--screw in another segment when it becomes necessary to massage data in another way. This is the way of IO also'.
  • It's an abstraction of IO. It improves latency, reduces memory footprint, expands possibilities and supports realtime.
  • Substack's stream handbook is a great resource.
  • Kinds of streams: readable, writeable, transform and duplex.
  • request, JSONstream, mux-demux, shoe, emit-stream, scuttlebutt or event-stream are all amazing tools for streams.
  • Problems with readable streams (for < 0.8): data eagerly fired whether ready or not, implement pause/resume.

Building non-trivial web apps which use websockets as the primary means of communication

presented by @socketstream

Check coverage from LXJS.


Observability for node.js and realtime software

presented by @dshaw | slides

  • @enterprisestack
  • Observability is hard — especially at scale.
  • Realtime app prorities: scalability and observability.
  • Observer tools: logging, log aggregation, health/status endpoints, REPL, monitoring, metrics, DTrace.

Distributed Systems with Node.js

presented by @hij1nx | Github repo for the project

  • In software we start with abstraction. It becomes very difficult to convey difficult ideas and have people understand.
  • There's a possibility that when we speak about technical things we use too much abstraction. If we are going to talk about software we should show code.
  • Let's implement gossip protocol /ht @dominictarr for his talk at Reject.js.

Colouring with crayons and playing with Duplo blocks

presented by @dominictarr | stream punks group on Github

  • Obviously duplo — modules
  • Colouring with crayons — shallow customizations
  • Studs = streams. Streams are not for fast IO. Streams are for connecting programs together.
  • Old-fashioned streams: unix streams. One way stream (readable XOR writable).
  • Full duplex is more interesting: ssh, rsync, git.
  • These streams involve two way communication. ssh is a handshake to auth and exchange secret keys. then duplex stream to the shell (by default). rsync uses a duplex stream from ssh and then a handshake.
  • Git is the same, although the structure of diff is different.
  • Duplex pattern: A.pipe(B).pipe(A) — some node modules with this pattern: dnonde, mud-demux, snob, scuttlebutt, crdt, repred.
  • A distributed system is scaled out servers, application with multiple processes, web/mobile application.
  • Instead of enforcing ordering we should be commutative, which means that order doesn't matter.

How to not write big apps!

presented by @substack

  • Big applications aren't fun. If something isn't fun you're just not going to do it.
  • First step: npm install.
  • Second step: npm publish — your code will be only growing if you're dependant only on different people solutions. Also, the community helps you to develop solutions.
  • Third step: http.createServer().

Hand Crafted Artisanal JavaScript: How to start a company and use JS for everything

presented by @maxogden | slides

  • A story of Gather.
  • Mapbox
  • We're using node as an communication system for phones.
  • We don't have a web framework. We use a modular approach.
  • We have two server-side templates.
  • We don't care about JavaScript syntax. Flow control. Callback hell.

How to build Products in Node

presented by @joemccann | slides

  • 16 195 modules available in npm.
  • Gunnar app
  • Dillinger.io — online markdown editor.
  • PhotoPipe
  • It's better to use ready modules and assemble them to make real products instead of writing new ones.
  • Dillinger wasn't modular, adding new functionality and features was painful. Also it was difficult to contribute due to dependencies.
  • Now it's modular, pluggable and easier to contribute.

End of day one


Day two

About Libuv Optimizations, Node.js Goals, Roadmap

presented by bnoordhuis | libuv on github

  • Libuv is a C library which provides async network and file I/O. It's cross-platform. +/- 40,000 lines of code, supports epoll, queue, event ports, IOCP.
  • Libuv is used by node, luvit, rust, julia and more
  • GYP — has JSON–structure, generate your projects.

V8 Performance Cost

presented by @starzi

  • V8 design philosophy: fast is better than slow, hard work often pays off after time.
  • Recipe: inline caching (when we compile we don't know the layout of objects, once we know how the objects look like we'll patch them), crankshaft (optimizing compiler), NewGC (incremental low-pause garbage collector).
  • Garbage collection is all about dead objects (?). It's about live objects! Mark and sweep collector — marking checks what's alive in the heap; sweeping looks at the gaps between live objects (not dead ones). These two processes are atomic pause, which somehow doesn't align with node.js architecture. In GC you need to distinguish white (dead) and black (alive). In the real life we have grey in between — which are unscanned objects. When talking about connections you can't go between black and white.
  • How incremental marking works? Mutator generates the graph, GC marks the step. Unfortunately then mutator changes A. Finally GC finishes marking and does sweeping.
  • Sacrifice space for speed/responsiveness. Being lazy leads to steady progress.
  • Best practices: try to initialise all properties in the constructor; add properties in the same order every time; avoid object layout modification of hot objects.

Observing Node Performance with DTrace

presented by @mrbruning | slides and resources

  • DTrace is a tool that allows dynamical instrumentation of code from app level and into the kernel. Can be safely used on production systems.
  • Uses: performance analysis, debugging, code coverage and finding out what is happening in your software.
  • Available on illumos, SmartOS and other Solaris 10 derivatives as well as *BSD and Mac OSX.
  • Terminology:

    System call request for an action by the OS.

    Probe is an instrumentation point in the code; dynamic and static probes are provided and new ones can be added. A probe is specified by a 4-tuple (provide:module:function:probename[action]).

    Action is executed when a probe fires.

    Predicate is an optional boolean to determine whether or not to execute the action.

  • With DTrace you can trace events in the node engine, node.js scripts and the kernel.

  • The dtrace-provider for node.js allows you to create statically defined probes (USDT) in your app.

Persona

presented by @mmayo

  • Persona — is attempting to solve security problems tackled by many developers. It's a product. Browser ID is a protocol.
  • How does it work? You load Javascript library, you set login and logout callbacks and add same buttons. Finally, verify proof of ownership (in JSON format).
  • Supports all modern browsers (mobile included).
  • login.persona.org = fallback IDP.
  • Why node? Javascript is in our blood, evented IO is alright, low memory footprint, interpreter is pretty quick.
  • Train-based release model, full QA cycle for each train, deployment asset isn't source code, security reviews and audits, unit, regression and fund tests on each commit, full load tests on each candidate.
  • Cryptography is brutally unforgiving of bugs.
  • Node compute cluster and node memwatch
  • Unsolved: backpressure, deployment, hitless rollouts, DB promotion still janky.

Dr. Devops, or How I Learned to Stop Worrying and Just Use More Node.js

presented by @ Av1anFlu

  • Node is the best thing happened to system programming since the discovery of caffeine.
  • Javascript was born in the browser, massively simpler parallelism, learning to deal with the hard parts takes weeks, not years (ie. callback hell).
  • Cowboy DevOps rules: shit. must. work.; production debugging sucks; don't burn out your Ops team; deputise your tech support; eat your own dog food (to excess; use your own services and tools).
  • SmartOS is pretty awesome — DTrace, ZFS. But moving production systems is extremely hard. Humans and chimps have probably more DNA in common than Linux and SmartOS have APIs in common.

Hackathon Strategies using Node.js

presented by @sarajchipps

  • Reasons for participation: lots of developers, food, swag and competition.
  • It's team building.
  • Do it fast and simple. Do one thing, just one sweet feature.

Geekli.st and doing cool stuff with Node.js

presented by @csanz

  • We're in revolution era, and we're trying figure out how to build things faster. Node is in the centre of this revolution.
  • Node is a community of passionate and amazing open source developers. The enablers.
  • Common trend is simplicity.

Something cool

presented by @nexxylove

  • node-firmata, johnny-five, shoe, arduino uno, ultrasonic sensor, breadboard and wires.

Community and Open Source

presented by @janl

  • This type of community will be disruptive outside technology itself.
  • Javascript will be good enough. We have small core. We have modules.
  • Node wants to be good at building network services. It doesn't try to be a framework. It focuses on doing one thing right.
  • We are building the future. We can create gold out of nothing.
  • We live such abstract lives and we get paid a lot of money for our work. We live in a sense of responsibility for other people.
  • We're in extremely privileged position.
  • Let's fork businesses the same way we fork code.

Decentralized Web: a vision for the future

presented by @falkvinge

  • Make money given constrains - that's the role of an entrepreneur.
  • Lulzitude.
  • Catholic church had a monopoly on the truth in the past. Monks were copying books by hand. Then there came printing press. The catholic church was outraged. They couldn't understand the idea of having many voices.
  • If you can dictate true from false, you wield the most power of all.
  • Driver, stoker, red flag waver.
  • We need a permission for everything from taking a shit to publishing a newspaper.
  • It's up to us to create the future. Authority is abundant.
  • Change doesn't just happen. Somebody makes it happen. Do you want to be that person?
Oct 3, 2012

Reject.js

The Next big thing? by @goloroden

  • "Node.js may be the next big thing" - why? It has non-blocking I/O is the usual answer, which can be sold to managers.
  • But non-blocking I/O has been implemented before, for example in Event Machine in Ruby or in Python.
  • This cannot be the deal maker for Node.js. What are the real reasons then?
  • First aspect: The future is asynchronous. Scale-out vs scale-up.
  • Writing multi-threaded code is hard. Functional languages can help you.
  • JavaScript is all about functions.
  • Node is single-threaded, natively asynchronous and uses a language which incorporates asynchronousity by default.
  • We all want realtime Web.
  • C10K problem - how do I run a web server that delivers to more than 10,000 customers? The answer is Web Sockets and streaming.
  • Node.js is built from the ground up to support streaming.
  • The future is JavaScript - that's the most world-spread language currently. Not everyone likes it though.
  • Single page applications are basically JSON. On the server side REST is basically JSON.
  • But the Web isn't all about streaming.
  • Node.js is cross-OS.

Distributed systems for real - time JavaScript applications by @dominictarr

  • MVC doesn't feel right. UI change ‹ model change == true
  • GIT a distributed version control system, if your program runs across multiple devices it's distributed, right?
  • diff computes changes in the file. diff file new file old | patch
  • diff3 computes the difference between three files - yours, mine and the older version - mine contestor yours.
  • Every node has it's own database. Intermittent connections (offline) aren't a problem.
  • Git is kinda complex. Most apps don't need the whole history. Also it's cumbersome to attach to UI.
  • Set of non-virgins (a grow-only set) - the effect of sex on your virginity is both idempotent and commutative.
  • A delete must be an update. virgins = born - nonVirgins (and hopefully born is always bigger)
  • Gossip protocol - nodes just connect randomly. There is no leader. When gossiping any node can connect to any other. Distributed patterns are super scalable (so you can use more resources).
  • Another approach - npm.im/crdt
  • npm.im/scuttlebutt is a base class for a replica table data type.

Browserver: A node.js HTTP server, in your browser by @jedschmidt

Rest of coverage coming up later

Sep 30, 2012

LXJS: Summary

Recently we've been to many conferences. We've visited Madrid for Spain.js, Zurich for Frontend Conference Zurich and now beautiful city of Lisbon for LXJS. There was no schedule besides section names which worked great in terms of attendance. The room was almost full even at 9 AM.

@dscape opening LXJS

@dscape opening the conference.

Also, organizers did a terrific job by making speakers life easier with free sim cards, prepaid custom LXJS cards and beautifully, hand-made tiles with the conference logo.

Venue

While I love really original, often industrial venues for conferences Mercado da Ribeira (which is a farmers market) was an odd choice for me. The venue was a little bit too noisy and there was a scent of fish in the air (which made it both kind of special and unbearable, at least for me). Chairs wasn't that comfortable either for sitting for two days, but we got through it.

What always goes wrong

What usually goes wrong at all conferences? Yes, WiFi. Try to name one with stable and fast Internet connection. It's hard, eh? The WiFi definitely was there but it went down couple of times and was a little bit slowish but @felixge managed to take care of that.

Another thing which is a constant issue (mainly due to venue restrictions) is catering. That might be foodie whining (since I consider myself as one) but I didn't get any decent food during my whole, over one week long stay in Portugal. Conference wasn't an exception. Plus for having fresh fruits as an alternative to sweet pastries.

Streaming and video coverage

The audio and video quality for online stream was really good, thanks to @anthonyallen. Videos were uploaded the day the conference ended, which usually takes a lot of time. Huge props for that. All coverage can be found on Youtube.

Highlights

I've attended every single talk on the first day and majority during second day. As a designer I must admit that it was extremely valuable. You could see that all talks were carefully prepared and rehearsed (remember that speaking is a job).

Audience

Some of the best ones:

  • Max Ogden covering advantages of writing a database in Node
  • As always entertaining and thought-provoking talk about current state of mobile by Brian LeRoux
  • Absolutely outstanding performance by James Halliday aka substack. I'm not sure what was more impressive - how fast he was coding or speaking. This is an absolute must watch. Also, do check substack's handbook on Streams
  • Very well-thought and inspiring talk by Jan Lehnardt about popularizing JavaScript
  • Some deep thoughts on distributed systems and the reduction of complexity by Paolo Fragomeni
  • Extremely entertaining robots talk by Felix with flying AR Drones. I would never think that it was so easy to control a freaking flying copter
  • Last but not least - the state of Node community by the godfather of NodeConf - Mikeal Rogers.

Thanks

Big thanks to all of organizers, mainly two friends of mine from Nodejitsu - Nuno and Pedro who did an amazing and very hard work of putting it all together so we could have this amazing community event.

Thanks from LXJS organizers

And that's the organizer team thanking us for attending.

Afterparty and goodbyes

When Mikeal Rogers closed the conference with his Untitled keynote immediately we were taken for a boat trip proudly sponsored by Adobe. Again it was a very original idea to wrap up a conference and we had tons of fun.

Boat.js sponsored by Adobe

What's still disappointing is the number of female attendees (I managed to spot five or six, from which one was Garann and second was me, so both speakers), but thanks to awesome initiatives such as the one from Jan and Tiffany I bet the situation will improve.

I've managed to see a lot of familiar faces. The community is still growing. It's definitely another quality event promoting JavaScript and Node in Europe.

Now off we go to Berlin for JSConf.eu. See you there!

Sep 29, 2012

LXJS: Day two

Javascript World Domination

@janl @janl

  • Internet is awesome.
  • Revolutions on the Web are additive. Not destructive. Native didn't kill HTML5. Facebook didn't kill email.
  • Why do we need Facebook to have a community?
  • Centralised Web we have today is on the wrong side of the history. A fully decentralised Web will build a better world
  • We must build the future. We need to be pioneers. We have all technologies to do so.
  • Google isn't the one and only company to build a compelling Web experience.
  • We have all the technology to do this right.
  • The focus needs to go for experience. That's what Instagram teaches us.
  • Open Source doesn't have to mean sucky user experience.
  • JavaScript is in a incredibly unique position to achieve that.
  • Node gives us a full control over back-end.
  • It's a community that knows that performance is as important as visual experience.
  • We need to have a mindset of reinventing things, making them better.
  • We will build APIs and policies to use them. HTML5 + node.js = <3
  • We need to build products for everyone.
  • Our tools need to be essential for users, the same as Dropbox or Skype.
  • We need to hack politics. Business isn't a natural thing for programmers. But we can fuel great ideas with it.
  • Why don't we use WikiPedia strategy and apply it to other services?
  • Let's reinvent all the wheels.

Network.js

@hij1nx @hij1nx

  • In the browser when user interacts you have an event. It's I/O.
  • The server is all about events too. Instead of clicks on the server-side you have data arriving through network.
  • Most platforms treat I/O as RAM, which is wrong.
  • Monolithic systems are very difficult to decompose. Cognitive indigestion is a byproduct of that.
  • How to measure complexity? It can be quantified as number of steps that system needs to take to be in desired state.
  • Node is great in I/O. So why we don't break our systems to small pieces? Each part should be a little black box - we need separation of concerns.
  • Distribution of responsibility.
  • Centralised systems are far less reliable.
  • Master-master solutions work way better.

@jchris @jchris


Node.js

@felixge @felixge

  • Parrot AR Drone is sold as a toy, controlled by iPhone or Android phone.
  • Parrot Drone has open and documented protocol, firmware is closed source, but alternatives are available (requires more work though).
  • A library for controlling the drone in a simple way on Github - Node AR Drone.
  • You can learn about debugging and running production systems.

Mad_science.js

@tmpvar @tmpvar


Community

@mikeal @mikeal

  • Objects have knowledge. But what it has to do with the community?
  • We need vocabulary to transfer knowledge. We succeeded to do that within Node community.
  • We have many patterns in Node. For example - error first and the rest follows, which forces us to evaluate mistakes first.
  • Github is essential for Node. We all share the language of contribution.
  • There are 85,000 modules in npm repository, over one million downloads per week. The vast majority of packages are working together. Even Ruby gems are not that popular.
Sep 28, 2012

LXJS: Day one

Fireworks

@seb_ly @seb_ly

  • We've seen so many people saying that designers should learn to code and meet developers halfway. On the other hand coders should learn to be creative.
  • Creative coding is all about iterating.
  • Experiment. Play. Share.

Database.js

@daleharvey @daleharvey

  • CouchDB invented the first telephone.
  • There isn't many applications which can't benefit from offline syncing.
  • Offline is a fact.
  • Sync is hard - Things to-do app spent two years working out the syncing mechanism. It's very difficult because of bad connections (protocols for recovery of dropping connections), you also need to minimize amount of data you're sending (only the data which actually was modified).

@maxogden @maxogden

  • When you want to write a database in JS they will usually ask if you meant Java. But it's actually worth considering. Node makes it possible.
  • Node is a glue layer for systems programming for evented I/O.
  • I/O is very slow in general.
  • Node makes databases in JS approachable (#jifasnif).
  • Node is bad at heavy computation (CPU bound operations)
  • Couch uses JS for indexing data.
  • Most databases are a stack. In Node you're dealing with modular approach instead.
  • Node is like Erlang except fun.
  • Use C to write to disk and JS to write to humans.

Empowering a new web

@socketstream @socketstream

  • Web started as GeoCities craziness and a bunch of static sites. Now we're consuming everything as dynamic. The next major phase of the Web is realtime - what you see is always up to date.
  • Every byte counts - most of the data we're transmitting is redundant. Even if it's cached it's still needs to be processed by the browser.
  • SocketStream is a node framework dedicated to building single-page apps. All application data flows over the websocket. It's sending minimal bytes of data.
  • Why bother with a framework? Good framework should provide the essentials and remove boring decisions but allow for personal tastes.
  • Essentials for realtime apps include code organization, preprocessors, connection handling, sessions, CDN support, asset handling, client-side templating and more.
  • SocketStream prioritises clean, efficient system for building modern realtime apps rather than SEO support.
  • Apps are temporary. The web is going towards fully using the hardware on your devices. It's all coming back to the web.

Browser.js

@limejs @limejs

  • Styler is a web-based tool for rapid development and realtime debugging.

@garannm @garannm | slides

  • Why MVC is so popular? Most successful server-side frameworks were based on MVC. It feels natural and intuitive for developers.
  • Is MVC is the answer? It's great for server-side, CMSes, data entry, multiple, clearly-defined object types and anything that fits easily with OOP.
  • MVC can be awkward - lots of complex user interactions, distinct, abstract controls/widgets, lots of client-side apps aren't well suited for MVC anyway.
  • MVC is an overkill for static sites and server-driven sites.
  • It gives a clear concept of the UI (view implementation) and maps neatly to original web apps.
  • It's a great starting point.
  • Event-driven architectures (parent to MVC) should feel natural to JavaScript developers.
  • What you should be considering? How much decoupling there is, whether the picture of application is decentralised, level of abstraction in controls and setup/initialization needed.
  • Real options for large static sites: EDA, pipelines, RMI.
  • Architecture is a tool to enforce style.
  • Performance changes felt more acutely, need careful balance with any inversion of control.
  • Use MVC instead of nothing. Fit patterns to apps, not vice-versa.
  • If you write a framework, try to solve a new problem.

@xcambar @xcambar | slides

  • Application development is like hiking. Be prepared for many files and dependency management, testing and security.
  • Modules must be context-free, must have no impact from its imports and exports. It may have dependencies and may expose an API.
  • Module loaders take care of loading dependencies when they're needed. They're not exposing modules publicly and may expose its own API.
  • Use modules for yours app sake. Get used to associated patterns.

@igorsoarez @igorsoarez | slides

  • Web Workers is an API defined by W3C and WHATWG.
  • They run in a separate thread, they have distinct event loop, no access to DOM, UI Elements, window, document, parent or console.
  • Workers can use navigator object,location object, application cache, importScripts(), create sub workers (subworker.js) and more.
  • You can use Web Workers for heavy I/O operations and coordinate multiple tabs with shared workers.
  • Web Workers are heavyweight.

Mobile revolution

@rik24d @rik24d

  • Moving into mobile: more sales of mobile phones than computers in 2011. And the same time we've lost control and packability in the process.
  • Most of the apps are created for iOS or Android. Moreover you need knowledge for each platform. In the meantime new platforms (such as Bada, RIM) are struggling.
  • The Web is the platform.
  • Enabling the Web - having the same capabilities are native apps and being out of the browser.
  • All WebAPIs will be a core part of HTML5.
  • Android is not enough - we can't rely on specific market share. Many markets don't have smartphones yet.
  • Boot2Gecko (now FirefoxOS) was open since July, 25 2011. Everything is a web app. It's build on a Linux kernel and Gecko (rendering engine of Firefox).
  • Find the demo here

Mobile.js

@twtomcat @twtomcat

  • Software development was limited for specialists some time ago.
  • Attempts to control the Web (for example with ActiveX).
  • The Web is an open source environment by design with 'view source'.
  • Openness is driving communities, which are founded on mutual respect and voluntary respect.
  • Are we approaching a second browser war? Or is it an ecosystem war between Apple, Google and Microsoft?
  • Apps must die. Just-in-time interaction.
  • Web development has low barrier of entry for programmers.

@paddybyers paddy byers

  • Everything that has a CPU will be connected to the web.
  • Things that we've used to write servers won't be usable anymore.
  • Android is still most accessible embedded platform.
  • Webinos is a DLNA for personal data - partners include BMW, Samsung, Fraunhofer.
  • Node cannot simply run as an executable.
  • Android only permits a single process for any given application, so multiple instances must exist as isolates. Isolate feature was implemented in v.0.7 and then it was gone.
  • Android framework for node.js applications

@brianleroux @brianleroux

  • Mobile is not first.
  • JS frameworks: try them all, and maybe use none. They're pretty bloated and may not support all devices.
  • iOS6 kinda broke HTTP.
  • Touch is a total mess, but it has been polyfilled.
  • Cavas and SVG aren't perforamant on mobile.
  • Media queries are cool but you're loading all assets anyway before you choose what to display and use.
  • Flexbox saves your life on mobile. The specification is changing rapidly though.
  • Southstreet Progressive Enhancement Workflow by Filament Group
  • Standards have to happen and they do work. They just need time.
  • Node.js needs to consider mobile because it's perfect for it.
  • Device APIs are the future of the web.

Realtime.js

@3rdeden @3rdeden

  • Why implement realtime? Better UX.
  • Realtime isn't new. First implementations are dated for early 90s.
  • Transport fallbacks - this is when frameworks would like socket.io to come in.
  • Socket.io works cross domain and in multiple processes, supports lots of transports and has huge community.
  • Sock.js was designed for single node.js processes or usage behind a load balancer.
  • Engine.io is a new socket.io backend.

@dshaw @dshaw | slides

  • Don't be afraid of logging. Not logging or severely limiting logging is a ridiculous premature optimisation.

@substack @substack

  • Streams are the most underrated feature of Node.
  • Some crazy streams sorcery which is very hard to follow :)

Open Source

@indexzero @indexzero | slides

Return button