read it

[mr-no-fairy-deactivated20190722]

MY BALLOONS CAME IN

[the-dw-blog1]

Jade.js: conditional attributes

I have been using jade for quite some time already, but fixed attributes in a wrong way (with jQuery). *Suddenly!*, after some struggle with a lot of rendering I have discovered a way to render conditional attributes in **``** tag, but it could be used with any attributes:

select(name="entity[status]", data-selected="#{entity.status}") option(value="green", selected=entity.status === 'green') green option(value="yellow", selected=entity.status === 'yellow') yellow option(value="red", selected=entity.status === 'red') red

if `entity.status` is `"yellow"` will generate:

green yellow red

PS. Tumblr has shittiest Markdown parser ever

[the-dw-blog1]

Another good book on JS, Node and Socket.io

[Smashing Node.js](http://smashingnode.com/) - sweet introduction to all that stuff. What I like the most: * approach from the V8 side: no more legacy and tricks of ie6 in JS * practical explanations of how things work * finally a good info on [Socket.io](http://socket.io/) from one of the authors The book itself is very well formatted and easy to read. Recommended to anyone interested in JS, Node or at least hype around them.

[the-dw-blog1]

Information: Future and Values

I have accept it as a fact: we do live in a future. All those flows of information from *Pocket* to *Twitter* to *Flipboard*, from device to device, from screen to screen, from person to person - they are truly futuristic. Seamless experience, smooth interactions and instant responses are common, standard, *normal* things today. It was more than ten years since as a user I had to wait hours and I even haven't noticed as waiting time came to the parts of seconds. But at the same time with all that speed and traction, with that overwhelming stream of information and data the value wained away. Even the greatest masterpiece could be treated only as a trend nowadays. Even more - information slips as fast as it comes. Can you show your notes, posts, mails to your grandchildren? Or at least re-read them in few years? Technically - sometimes 'yes', but practically it's almost impossible thanks to current way of thoughts. I want to change that while we could. Otherwise a lot of art and aesthetics will be gone, as well as life force and dreams. And that is something not acceptable.

[the-dw-blog1]

Why do I care about consoles, but not their specs

[Tech Analysis: How Powerful is Tegra 3?](http://www.eurogamer.net/articles/df-hardware-how-powerful-is-tegra-3) by Eurogamer was provoking enough for me to write some stuff on games and consoles today. ###Tech: Yep, it's common to get cool games from cool platforms. But it's not always about numbers in specs. Actually it has nothing to do with them, IMHO. 1. Games are not about graphics, but picture. FEZ, Pokemon, Dragon Quest (on DS) all look great. Do they need super-pro-ultra hardware? No! They need developers to create them. Yes, there are games with high demands, but why nobody cares that they work on pretty old consoles (and both ps3 and xbox are old already) but everyone still have to care about videocards on pc? 2. Consoles are not about specs, but about comfort and easiness for user to understand and play. Do you know what processor is used in your blu-ray player? Or washing machine? Probably no. And as users we don't even have to care, since we interact with device itself, not his internals. While everything is fast, comfortable and nice looking (as mentioned above) I **don't care** how they do it. I want comfortable gamepad, good picture (as in above) and the most important - good game. 3. Consoles are not so much about hardware, but software. Do I need extremely advanced cool videoconsole without games? Nope. Actually, I don't see the difference between 30fps and 60fps. Why? Cuz I'm concentrated on the game, not some weird numbers. I want to get good games with easiness and play them with comfort. And I don't care where it comes from while those demands are fulfilled: it could be ps3, xbox, pc, toaster - the main point that I don't want and should not care about all those preparations as disks, accounts, passwords, security checks etc while I **just want play game**. ###Developers Developers Developers Yep, no creators - no games. But why nobody talks about how good their consoles are for developers, giving some numbers instead of that? There were only two exceptions I can easily remember: Xbox and OUYA. And Microsoft got a lot of indie games thanks to their claims of how it is easy to develop for them. 1. Comfort. Why nobody talks about support from platform owners to developers? Or advances of dev-kits and availability of frameworks? Freaking weird :/ AFAIK now PC is the best for simple and fast development of the game, same for distribution and sales. Apple put a lot into developers and got a ton of apps (great included). But what about next-get consoles? I don't know. 2. Price. I don't really believe that OUYA's 'almost zero price for dev-kit' is important. Developers' time could be way more expensive than dev-kits. I remember price-of-development comparisons from the last console generation shift. Why is it becoming more and more expensive and takes ages? Why don't platform owners try to make it cheaper to make a good game? Yes, there are some movements from MS, but is it enough? 3. Profit The most important (great products apart) thing for professional - get paid. It's about developers works (promotion, game quality, hype etc), but at the same time platform should provide the most essential part - store (or any other way for ppl to send money to developer). And as for now most of the stores are crappy (xbox marketplace was good, but they ruined it with all those new updates, imho) - or ppl cannot find your game or you have to wait a lot for some promotion from platform owner. While it's like that - nobody wins. --- Again. OUYA, Tegra, whatsoever. As user, I want to get game: * With comfortable gamepad/input interface * On platform I own/could easily buy * Having good picture (2d, 2.5d, 3d - I don't care) * That is easy (both in price and store-accessibility) to get * With next-good-game (sequel or not I don't care) release in less than 1 year from same developers ###And I want it to be a common practice for games be made and delivered like that.

[the-dw-blog1]

Oh yes,

If you think that I really care about: http://deniswolf.net/post/24283242817/religion-and-all-all-all and http://deniswolf.net/post/24282582308/42-01 ... Nah, I don't care. Was just playing around with text and language after watching Religulous*. *BTW, it has a lot of references to different religions and names of a lot of gods, so, obviously, I cannot recommend it to my jewish brothers and sisters. Don't you dare to take a peek!

[the-dw-blog1]

Religion and all all all

Why people are shut whenever it's about nuclear physics, but imagine themselves experts in Universe whenever it's about religions and Genesis? Because it's so easy! You always have excuse like 'oh, it's my religion, views and believes!'. And even more: whenever one sees visions and hear voices it's considered as madness and medicated. But when the same illness have anything with religion... you cannot touch it! Even further: politicians are not allowed to be intime with prostitues or cheat on their wives in other way, but... they are allowed to lead people for murders and wars on basis of... few books. That are approved by science on the same level as any fiction - and by that I mean 'not at all'. I call for mass medication and treatment, I call for education instead of mystification, I call for sense and reason. #And even while it was stated thousand of times, billions are influenced by scums and lunatics.

[the-dw-blog1]

Life, Universe and everything

That's how I understand things for now. Comment, please, if needed. Let's put away all mystifications and propaganda and look at world as we (educated middle class in Western civilization) know it now. We have already enough of answers to Universe to live with knowledge, not blind faith or fear. And on that let's count: ## Life and Death ### pro: Genetic shows that our genes are inherited by children and close to those of siblings. So person lives as genetical material after death in his children and relatives. And social sciences are talking about about a half of behavior and habits being inherited from learning and live examples. And on that we all live in people we communicate with. ### cons: Visions of light, persons etc in state close to death are documented, but those are hallucinations of damaged or stressed brain. ## Genesis ### pro: There are few theories how Universe was created. Physicists are working on them. There are more detailed and stated theories about Earth and Solar system. With no mysterieas or supernatural powers. Talking about humans and all other species: theory of evolution is stated as current most approved theory. As for now - only minor details could be changed, while we have great basis of approves and facts. ### cons: It's stated that Universe cannot be created in few days. Or in few thousands. Even more - there are fact and evidences that humans exist at least for more then hundred thousand years, while Earth exists for few bilions of years, at least. There is no any evidences of supernatural influence at any level. ## Creator ### pro: There are laws of sociology, biology, physic etc. They just are. We discover more and more of them, while polishing our understanding. We can test and approve them. ### cons: There is no approval or disapproval of any entity behind them. People who hear 'voices' and see 'visions' are approved to be insane or under influence of drugs. It was medically approved. ## Infidels ### pro: Even now science changes every day and scientific views progress. Some of old theories was corrected, approved of disapproved. But still they are tested, evaluated and documented. ### cons: Through all history there were few general ideas behind religious and philosophical views: * to keep control over masses * to get money from naives * to explain existence based on pure fiction * to explain existence based on facts Last one dominated nowadays, because it can approve itself while based on facts and observations. Scientific facts while instantly tested and approved, cannot lead to dominance of a person or group of persons. Even though there are a lot of attempts to copycat science for political purposes. But whenever you see as science is used for excuses to get money or power - it's not science anymore. ## Universe ### pro: It's huge and barely possible to understand in whole. ### cons: But we know more and more of it. And all supernatural statements from religions are discovered to be wrong, often on purpose or if not wrong could be explained in scientific way without any supernatural entities, mysteries or miracles. ## The end of days ### pro: We have enough information to say that humans, life on Earth or Earth itself could be destroyed. ### cons: None of those information includes supernatural powers, but physical (nuclear bombs, for example), biological (viruses), political (wars) or astronomical (comets, meteorites) reasons.

[the-dw-blog1]

Do you create? Then watch it!

Get enlightenment with Simple Made Easy

Get way with Hammock Driven Development

And learn how to do it in real life now: RDD, practice of RDD

[the-dw-blog1]

On Simplicity and JavaScript

Language is one of those amazing things that we experience everyday on every level.

Greatest writers and young children use it. One use it while lecturing and while drunk (or both at the same time). It could be different, richer or poorer dependable on the context, but it is still the same. And what makes it so flexible and adequate for each and every situation - is simplicity. From streets to academies the core of the language is the same, basic words either.

With that, while we have basic core of JavaScript and it's stable and performance-acceptable, all those toppings alike CoffeeScript, ClojureScript whatsoever - are valid and have future. And they will fix most of those flaws and problems with stupidity of W3C, idiotic decisions of TC39 etc will be compensated and smoothed by brave and wise users.

So the hell with ECMAScript 6 and IE - let's write what we want and make people love it.

[the-dw-blog1]

Occasionally it had been deleted, but it worths mentioning.

[the-dw-blog1]

browser testing

http://www.webkit.org/perf/sunspider/sunspider.html

mac-mini 2010, Chrome 10 * Total: 387.6ms +/- 4.0%

mac-mini 2010, Chrome 11 * Total: 320.3ms +/- 2.5%

mac-mini 2010, Safari 5.0.4 * Total: 374.2ms +/- 2.0%

iPad (first ed.) iOS4.2 * Total: 7695.3ms +/- 0.2%

iPad (first ed.) iOS4.3 * Total: 3231.2ms +/- 0.2%

iPhone4 (not my info) iOS4.3 * Total: 4013.4ms ± 0.6%

[the-dw-blog1]

Readme Driven Development by creator of GitHub Tom Preston-Werner

What to do BEFORE BDD and rest? Write you f*king README already! I wish most developers to do their projects in such way :/

[the-dw-blog1]

Place a rubber duck on your monitor and describe your problems to it. There's something magical about stating your problems aloud that makes the solution more clear.

[the-dw-blog1]

Everyday GIT: New Branch, Squash, Merge

It's common to implement features in your own local branch, then merge it into master as ordinary commit. But somehow it occures to be not obvious for many developers. So, I will explain how to deal with it below:

1. Ordinary preparations:

$ mkdir learn_git $ cd learn_git/ $ echo 'master of all branches' >> master_file.txt $ git init [ master ]$ git add . [ master ]$ git commit -a -m 'first commit. branch master'

2. We are on [master] branch. Let's create our own one for new feature:

[ master ]$ git branch * master [ master ]$ git checkout -b new_feature Switched to a new branch 'new_feature'

3. Then we will make some editions, new files etc...

[ new_feature ]$ echo 'new feature file' > new_feature_file.txt [ new_feature ]$ git add . [ new_feature ]$ git commit -a -m 'first commit in new branch' [ new_feature ]$ echo 'with a stroke of new features' >> master_file.txt [ new_feature ]$ git commit -a -m 'second commit in new branch' [ new_feature ]$ echo 'last words before arrival' >> new_feature_file.txt [ new_feature ]$ git commit -a -m 'last commit in new branch'

4. And end up with few commits in our new branch:

[ new_feature ]$ git log --oneline a735697 last commit in new branch 1c582c8 second commit in new branch 0f00df1 first commit in new branch 85457f9 first commit. branch master

5. And most intriquing part: squashing commit into single one:

[ new_feature ]$ git rebase -i master pick a0f9fc2 first commit in new branch pick 986dfb2 second commit in new branch pick 24d5963 last commit in new branch

6. Here we are. Top (oldest one) commit should be kept as is. Others should be squashed:

If something terrible will occure - just correct it, add and commit (git 'll explain it all if needed)

Attention! Don't correct commits' comments on squash/pick step, there would be second one, especial for that.

pick a0f9fc2 first commit in new branch s 986dfb2 second commit in new branch s 24d5963 last commit in new branch

... and usual 'add commit' after that

7. So, we have almost done it. Let's checkout master and merge our branch:

[ new_feature ]$ git checkout master [ master ]$ git merge new_feature

Some advices:

I make 'git pull --rebase master' between commits in branch, 'cause our developer-trunk changes frequently and merging on fresh changes is really easier than after some days later.

Use git-completion for bash, it's great opportunity for watching your current branch.

[the-dw-blog1]

ScalaxyCat

[the-dw-blog1]

Io: параллельные вычисления

Продолжим знакомство с Io. ВоровствоПеревод нескольких абзацев третьей главы из книги Seven Languages in Seven Weeks.

Почему без второй главы да и то не целиком третью? Во-первых чтобы купили и почитали оригинал :D А в нулевых от того что хотелось пересказать действительно интересные вещи. Причем хотелось так сильно, что я вынужден констатировать: "мой беглый письменный русский ужасен".

Окончательно испорить оригинал помогут мои комментарии и ссылки.

Параллелизм (Concurrency)

По моему, Io позволяет очень легко, просто и быстро познакомиться с теми concurrency вещами которые все еще не знакомы широкому кругу IT специалистов, но уже становятся весьма популярны и модны как в новых (и заново открытых) языках программирования, так и проектах.

В Io - поистине выдающиеся библиотеки для параллельных вычислений. Перечислим основные: сопрограммы (coroutines), акторы (actors), фьючеры(futures).

Сопрограммы - они же greenlets, они же coroutines (кстати в Go есть еще похожая, но не идентичная вещь - goroutines), реализованы давно и в очень многих языках. Википедия

Акторы - фирменная "фишка" Erlang. Но появились они еще до этого немолодого языка. Actor Model на Wikipedia и Агент-Ориентированный подход там же, но на русском

Фьючеры - то Io первый язык в котором я встретил данный термин. Как иначе перевести на русский - пока идей нет. Пожалуй именно они больше всего впечатлили при чтении книги (про акторы я уже знал). Wikipedia

Coroutines

Основой для параллельного исполнения являются сопрограммы. Сопрограмма позволяет свободно (т.е. когда этого захочет разработчик) откладывать или возобновлять исполнение процесса. Сопрограмму можно представить как функцию с несколькими точками входа и выхода. Каждый вызов (yield) может приостановить текущий и перейти к другому процессу. Запустить сообщение в асинхронном режиме можно указав @ или @@ перед его названием. Первый способ вызовет фьючер (позднее), а второй вернет nil и запустить процесс в собственной нити (thread).

Например:

vizzini := Object clone vizzini talk := method( "Fezzik, are there rocks ahead?" println yield "No more rhymes now, I mean it." println yield) fezzik := Object clone fezzik rhyme := method( yield "If there are, we'll all be dead." println yield "Anybody want a peanut?" println) vizzini @@talk; fezzik @@rhyme Coroutine currentCoroutine pause

fezzik и vizzini - независимые экземпляры Object с сопрограммами. Мы асинхронно запускаем методы talk и rhyme. Они выполняются параллельно, передавая через сообщение yield контроль друг-друг через указанные интервалые. Указанная в конце пауза (pause) заставляет программу дождаться выполнения всех асинхронных сообщений и только потом завершить работу. Сопрограммы - отличное решение для задачи требующей согласованной многозадачности. В приведенном примере два процесса легко справляются с задачей подобного типа - чтения стихов:

batate$ io code/io/coroutine.io Fezzik, are there rocks ahead? If there are, we'll all be dead. No more rhymes now, I mean it. Anybody want a peanut? Scheduler: nothing left to resume so we are exiting

В Java и C-подобных языках философией параллельного исполнения является вытесняющая многозадачность. И когда вы объединяете подобну стратегию параллельной работы с объектами, обладающими изменяемым состоянием, то на выходе получаете программу с сложно предсказуемым поведением, которую к тому же распространенными техниками тестирования нельзя проверить. С сопрограммами ситуация обстоит иначе. При использовании сопрограмм, приложение может свободно передать контроль в предсказуемый момент. Распределенный клиент может передать передать контроль другой части программы на время ожидания ответа от сервера. Рабочий процесс волен приостановить (pause) свою работу после обработки очереди элементов.

Сопрограммы - базовые, основные строительные блоки для более высоких абстракций, таких как акторы (actors). Акторы можно рассматривать как универсальные паралелльно исполняемые примитивы которые могут посылать сообщения, обрабатывать сообщения, а также создавать новые акторы. Сообщения, которые принимает актор, параллельны (concurrent). В Io актор располагает в очередь и обрабатывает содержимое этой очереди с помощью сопрограмм.

Далее рассмотрим акторы подробнее. Не поверите насколько просто писать код с их помощью.

Акторы (Actors)

Акторы обладают огромным теоретическим преимуществом перед нитями (threads). Актор меняет свое состояние и общается с другими акторами только через тщательно контролируемые сообщения. Нити же могут изменять состояние других нитей как без каких-либо ограничений. Нити подвержены такой проблеме параллельного исполнения как race conditions, когда два треда пытаются получить доступ к одному ресурсу в одно и то же время, что ведет к непредсказуемым результатам.

И здесь раскрывается прелесть Io. Посылка асинхронного сообщения объекту делает его актором. И все! Рассмотрим простой пример. Для начала создадим два объекта, faster и slower:

Io> slower := Object clone ==> Object_0x1004ebb18: Io> faster := Object clone ==> Object_0x100340b10:

Теперь к каждому добавим метод start:

Io> slower start := method(wait(2); writeln("slowly")) ==> method( wait(2); writeln("slowly") ) Io> faster start := method(wait(1); writeln("quickly")) ==> method( wait(1); writeln("quickly") )

Мы может последовательно вызвать оба метода одной строкой кода:

Io> slower start; faster start slowly quickly ==> nil

Как видно - стартуют методы по порядку, потому что для посылки второго сообщения должно сначала выполниться первое. Но мы можем легко отправить выполняться каждый объект в собственном потоке (thread), добавив к имени сообщения @@ : Io> slower @@start; faster @@start; wait(3) quickly slowly

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

Фьючеры (Futures)

Завершим рассказ о параллельных вычислениях концепцией фьючеров. Перевода этого термина я не обнаружил, да и вообще концепция такая нечасто упоминается в сколько-нибудь давних (а значит - переведенных и распространненых) изданиях. Хотя сама по себе не так уж нова. Подробней почитать можно на Wikipedia.

Фьючер - объект, гарантированно возвращаемый после вызова асинхронного сообщения. Обработка сообщения может занять продолжительное время и значение фьючеру будет присвоено только по ее заврешению. Если обратиться к значению фьючера до этого момента - придется ждать завершения обработки, а процесс до тех пор будет заблокирован. Допустим что у нас есть метод, который требует некоторое продолжительное время для исполнения:

futureResult := URL with("http://google.com/") @fetch

Можно вызвать метод и произвести какие-либо иные действия до получения его результата:

writeln("Do something immediately while fetch goes on in background...") // ...

Затем пробуем использовать то что лежит внутри фьючера:

writeln("This will block until the result is available.") // выпролнится сразу writeln("fetched ", futureResult size, " bytes") // а вот уже этот блок придется подождать - до тех пор пока не будут выполнены вычисления // и Io выведет значение фьючера ==> 1955

Участок кода с futureResult немедлено вернет в качестве результата объект - фьючер. В Io фьючеры реализованы не через proxy (proxy implementation)! А уже объект фьючер будет блокиратором до тех пор пока самом этот объект не получит значение. Таким образом значением будет являться объект Future до тех пор пока не прибудет результат, а затем все экземпляры вызванного объекта будут указывать на итоговый полученный результат вычислений. Консоль выведет строку с последним возвращенным значением.

Фьючеры в Io также осуществляют автоматическое обнаружение взаимных блокировок (deadlock). Очень приятный моммент и делает использованию фьючеров еще легче и доступней.

На этом перевод глав про Io я хотел бы закончить. Во-первых, как уже упоминалось, материалов про Io на русском достаточно для того чтобы начать писать, а во-вторых чего-то еще интересного в Io я пока не нашел (хотя того что есть уже более чем немало!).

Комментарии и ругань по переводу можно направить мне лично или на почту: [email protected]