dmitriid

# Plugins
#
# Плагину достаточно выставить наружу command, принимающую context
#
# Где context — это 
# %{ :scope => :jabber, # или там :slack или там :icq
#    :from => ...,
#    :to => ...,
#    :room => ...
#  }

dmitriid

Running

> ies -S mix
elixir> Slax.Monitor start

Source

##mix.exs

dmitriid

// @mariuslundgard
// The component
import {pluckSwitch} from './stream-helpers'

function main (sources) {
  const sinks$ = NodeComponent({...sources})
  // etc.

  return {
    DOM: pluckSwitch('DOM', sinks$),

dmitriid

The problem concerns the following: How to properly isolate components in lists, and work with events from those components?

Problem description:

• retrieve a list of objects (called events) from the server
• create and display a list of these events
• each event display has a "Sign up" button. When clicking this button we should produce a reaction to the corresponding event

Given the code below:

• The HTTP request is for some reason performed twice (should happen only once, on startup).

dmitriid

start() ->
  case chain([ fun some_fun/1
             , fun some_fun/2
             ....
             ], SomeData) of
    {error, _} = E -> E;
    {ok, Output}   -> Output
  end.
  
some_fun1(Input0) ->

dmitriid

- Vladimir Vladimirovich, what is two times two?
- I'll be brief. You know, just the other day I was at the Russian Academy of Sciences
  and had a discussion with many scientists there, including young scientists, 
  all of them very bright, by the way. As it happens, we touched upon the present problem,
  discussed the current state of the country's economy; they also descibed their plans 
  for the future. Of course, the number one priority for them is the problem of relevancy;
  also, just as important is the question of housing loans, but I can assure you that all
  these problems can be solved and we will direct all our efforts to their resolution in 
  the nearest future.
  Among other things this also applies to the subject you raised in your question.

dmitriid

The question

tl;dr: Closure compiler makes little to no sense outside of Google's ecosystem.

Nolan Lawson conducted a very nice research on how various Javasctip tools bundle/compile Javascript. I highly recommend it: The cost of small modules.

This article has made several rounds on Twitter and many people have asked: Why aren't more people using Closure? There are many reasons for that.

Considering the dire state of Javascript tools today, Google's Closure compiler is yet another cryptic, badly configured, half-baked tool to throw into the ever-groing pile of twigs and sticks called Javascript infrastructure.

dmitriid

/*
 * No hyperscript helpers
 */


import { h } from '../../snabbdom.wrapper'
import UserStore from '../../stores/UserStore'
import Link from '../components/Link'
import Form from '../components/Form'

dmitriid

package com.dmitriid;

import com.amazonaws.auth.AWSCredentials;
import com.amazonaws.auth.BasicAWSCredentials;
import com.amazonaws.services.s3.AmazonS3;
import com.amazonaws.services.s3.AmazonS3Client;
import com.amazonaws.services.s3.model.CannedAccessControlList;
import com.amazonaws.services.s3.model.ObjectMetadata;
import com.amazonaws.services.s3.model.PutObjectRequest;
import com.amazonaws.util.Base32;

dmitriid

Lose-lose situation with Web Components.

Polymer is the leading implementation of Web Components and functionality on top of Web Components.

If this is Web Components spec, it's horrible. Lose

<template>
 [[name.first]] [[name.last]]