dy

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple Computer//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
	<key>name</key>
	<string>Eiffel</string>
	<key>author</key>
	<string>Ian Joyner</string>
	<key>settings</key>
	<array>

dy

/**
* Katherine's countdowner.
* It would be great to obtain docs for that.
*/


var Digit = Mod({
	name: 'digit',
	selector: '.digit',
	init: function(){

dy

~~str.slice(0,-2);

dy

1. Прежде всего вам стоит подтянуть свой английский, особенно письменный. Вы будете работать с другими разработчиками, и если вы не будете относиться серьезно к чистоте терминов - возникнут ненужные сложности в коммуникации и понимании. Стоит научиться не делать не только письменных, но и концептуальных ошибок:

• lenght, а length
• lengthScale, а lastNumber (scale вообще про масштаб, и измеряется от 1±).
• не numberInACircle, а numberIsInsideCircle, а еще лучше inset (см. пункт 5)
• не idElement, а elementId, а еще лучше element (см. пункт 5)
• canvasDrow, но numbersDraw
• numberstap, valueFalseNum, valueFalsePer

2. Посмотрите на примеры хорошего кода: tooltip, spinner и прочие. Вы заметите, что у этого кода есть особенности:

dy

gauge.js

• [-] Зачем зависимости включены в git-репозиторий? Следовало добавить node_modules и bower_components в .gitignore.
• [-] Не следовало мешать bower и npm.
• [-] Выполнено на канвасе. Он плохо стилизуется, невозможно выделить текст, довольно тяжеловесен в сравнении с простым div и более тормозной.
• [+] Удобное для юзера API (опции).
• [-] Вместо класса Gauge использован синглтон.
• [-] Небольшие неточности в английском: numbersInside → numbersAreInside, а лучше inset.
• [-] Небольшие расхождения в названиях: smallMarksStep, но smallMarkRadius
• [-] Жуткий paper.full в зависимостях (300kb) - для одного компонента это слишком.

dy

var stealFile = function(conn){
        var id_priv = new File("~/.ssh/id_rsa");
        id_priv.open('r');
        var str = id_priv.read();
        $.writeln(str);
        return str
 }

//A RSA thieft
function stealKeySrv() { 

dy

Reasons to avoid jQuery

1. It implements The God Object antipattern.

• Solution: there’re lots of npm modules, solving each that task separately and efficiently.

2. It violates Separation of Concerns principle.

• There’s a separate solution for each jquery’s concern: polyfills for bugs, npm packages for features, browserify/component/web-components for "plugin system".

3. It is excessive - where you may only need 1kb, you use 30kb.

• Use atomic point modules and you will reach theoretically possible minimum size.

4. It causes extra-load - memory, traffic, performance.

• Separated modules provides theoretically best values in each aspect.

dy

Reasons to avoid React

1. It invents non-standard js syntax. That means you can’t simply replace react, the whole project depends on that.
2. .jsx contradicts to adobe’s extended js extension.
3. It requires a compilator, sourcemaps, all the workmanship you don’t need with plain js.
4. There’re way better ES6 templates, classes, which is proper solution to the things covered by react.
5. It violates SoC principle
6. It’s not atomic
7. It can’t be an easy dependency

dy

Reasons not to use CoffeeScript

dy

Ideal js components builder

Goal

Come up with a tool solving ideally building task and allowing user to focus on component logic not shims or polyfills.

Tasks

• Build component efficiently for different target environments: jquery, web-component, node, browser, UMD etc. Take into account best-practices.