Доброго времени суток. Это статья — перевод заинтересовавшего меня поста в блоге аспиранта Университета штата Нью-Йорк в Стоуни-Брук. Статья в доступной форме описывает основные концепции функционального программирования, их преимущества и недостатки. Думаю она будет полезна широкому кругу читателей, которые сомневаются, нужно ли им углубляться в мир функционального программирования или нет. Пожелания, предложения и замечания по переводу и терминологии принимаются по личной почте.

Мнение переводчика может иногда не совпадать с мнением автора, но переводить статью было крайне занимательно.

UPD: альтернативный вариант перевода вы можете найти на rsdn (спасибо flamingo за ссылку).

Введение

Как настроить nginx в качестве frontend к apache и зачем это нужно — написано неоднократно, в том числе и на Хабре. Мой случай немного отличается от классического. Начиналось все как обычно, проект на apache, увеличение количества посетителей и, связанная с ним, недостаточность ресурсов сервера. Но проект использовал SSL для защиты обмена данными с клиентами. С чем я столкнулся и как решил проблемы я расскажу под катом.

Предисловие

Я капризный. Я жалуюсь о многих вещах. Многое в мире технологий мне не нравится и это предсказуемо: программирование — шумная молодая дисциплина, и никто из нас не имеет ни малейшего представления, что он делает. Учитывая закон Старджона, у нас достаточно вещей для постижения на всю жизнь.

Тут другое дело. PHP не просто неудобен в использовании, плохо мне подходит, субоптимален или не соответствует моим религиозным убеждениям. Я могу рассказать вам много хороших вещей о языках, которых я стараюсь избегать, и много плохих вещей о языках, которые мне нравятся. Вперёд, спрашивайте! Получаются интересные обсуждения.

PHP — единственное исключение. Фактически каждая деталь PHP в какой-то мере поломана. Язык, структура, экосистема: всё плохо. И даже нельзя указать на одну убийственную вещь, настолько дефект систематичный. Каждый раз, когда я пытаюсь систематизировать недостатки PHP, я теряюсь в поиске в глубину обнаруживая всё больше и больше ужасных мелочей(отсюда фрактал).

PHP — препятствие, отрава моего ремесла. Я схожу с ума от того, насколько он сломан и насколько воспеваем каждым уполномоченным любителем нежелающим научиться чему-либо ещё. У него ничтожно мало оправдывающих положительных качеств и я бы хотел забыть, что он вообще существует.

Computer Scientist, Software Engineer и Coder заходят в бар.
— О, а вот и программисты! — окликает их бармен...

Я знаю людей, которые программируют уже не один десяток лет, но обижаются, когда их называют "программистами". А по запросу Coder vs Developer vs Software Engineer в гугле находится 113 000 000 ссылок: 1 2 3 4 5 6 7 8 9 … 113 000 000. Что интересно, можно найти совершенно противоположные мнения об одном и том же. С чем-то я согласен, а с чем-то в корне нет.

Последние же несколько лет так вообще постоянно подливают масло в огонь, появляются какие-то совсем странные программисты, которые называют себя Creative Technologist, Creative Coder и Interactive Developer.

Давайте же попробуем разобраться.

Недавно Яндекс анонсировал свой новый сервис, подобный DropBox'у. Многие его сразу же начали поливать из ведра, хотя, я думаю, зря.

Один из плюсов лично для меня, линуксоида — не нужно устанавливать дополнительные приложения, как в случае с DropBox'ом. Сервис можно подключить через файловый менеджер Nautilus, используя WebDAV. Что я, собственно, сразу же и сделал.

Однако, я не стал на этом ограничиваться, ведь гуёвый доступ — не совсем хорошо, консольки никто не отменял.

Meteor представляет собой набор новых технологий для быстрого создания высококачественных веб-приложений, с которым справятся не только опытные разработчики но даже и новички.

Чистый JavaScript.

Пишите всё приложение полностью на чистом JavaScript. Все API, доступны на клиенте и на сервере — в том числе API базы данных! — Так что один код может легко работать на клиенте и на сервере.

Живые обновления страниц.

Просто напишите ваши шаблоны. Они автоматически обновляются при изменении данных. Meteor поддерживает любой язык шаблонов.

Чистая, мощная синхронизация данных.

Пишите ваш код клиентской части, как если бы она была запущена на сервере, и имела прямой доступ к базе данных. Больше не придется получать данные через REST.

Эта статья открывает серию статей — если окажется, что Хабраколлеги сочтут ее интересной, ибо первое правило публичных выступлений гласит: рассказывай людям о том, что им интересно!

Если вы раньше не выступали на публике или боитесь это делать — вам под кат. Если вы считаете себя опытным докладчиком, для вас будет вторая статья серии.

В сегодняшней статье я пишу о том, как выступать, и очень мало пишу о содержании доклада. Если из комментариев станет понятно, что надо еще рассказать о композиции доклада (постановка задачи -> варианты решений -> процесс выбора -> выбранное решение -> результат) или об основах публичной речи (не «экать», не «мыкать», не говорить через слово «т-скыть» и не заканчивать фразы ненормативными междометиями) — расскажу в следующий раз.

Историческая справка: на Хабре по этой теме уже было небольшое обсуждение год назад.

В этой статье я постараюсь кратко и емко рассказать что такое горутины, когда стоит их использовать, какое отношение они имеют к системным потокам, а так же как работает планировщик.

Что за горутины?

Горутина (goroutine) — это функция, выполняющаяся конкурентно с другими горутинами в том же адресном пространстве.

Запустить горутину очень просто:
go normalFunc(args...)

Функция normalFunc(args...) начнет выполняться асинхронно с вызвавшим ее кодом.

Обратите внимание, горутины очень легковесны. Практически все расходы — это создание стека, который очень невелик, хотя при необходимости может расти.

Сколько вешать в граммах?

Чтобы было проще ориентироваться, рассмотрим цифры полученные опытным путем.

В прошлом году я делал обзор книг, на которых реально растут люди и реально улучшаются процессы.



Тогда понадобился год, чтобы прочитать в десять раз больше бумаги и сделать выборку, которая оказалась неожиданно полезной многим. Вот результаты ещё одного года — ещё N+2 книги для бизнеса, которые реально помогают.

С технической точки зрения юнит-тесты – это очень простой инструмент, основанный на паре несложных концепций: (1) тестируемый класс, (2) набор тестовых методов, завернутых в некоторый класс и (3) набор методов, с помощью которых можно удостовериться в том, что состояние тестового класса соответствует (или не соответствует) некоторому значению.

Это очень простая штуковина, которая может кардинальным образом повлиять на процесс разработки в целом. С одной стороны существует TDD (“test-first approach"), при котором тесты «драйвят» не только процессом кодирования, но и процессом проектирования (т.е. дизайном системы). С другой стороны существуют разработчики с противоположной точкой зрения, которые считают юнит-тесты пустой тратой времени, потому что они не приносят никакой ценности пользователю.

Доброго времени суток!



В полку Open Source прибыло! Мы (@kulakowka, k12th, dhomich и я) рады представить вашему вниманию перевод официальной документации по Backbone.JS — каркасу для создания RIA приложений на JavaScript, автором которого является Jeremy Askenas — создатель CoffeeScript.

Добрый вечер всем хабраюзерам!

Хочу поделиться определёнными идеями и соображениями на тему создания обособленных проектов в Yii на основе одного общего ядра.

Некоторое время назад, перейдя по рабочей надобности с kohana на yii, я долго радовался его простоте и удобству, которые, как мне казалось, были в разы больше, чем у коханы (да простят меня любители этого фреймворка), а потом, все по той же рабочей надобности, пришлось углубиться в архитектуру Yii, и, частности, в возможности дистрибуции его проектов от одного обособленного ядра.

Изначально, что называется, «из коробки», Yii уже поставляется отдельными папками с самим ядром и несколькими демо-проектами на нём, но мне этого было мало, поскольку требовались несколько другие возможности по управлению и контролю за проектами, на основе чего и были созданы те идеи, которые я хочу изложить.

Добрый вечер уважаемые читатели,

На хабре последнее время проскакивало несколько упоминаний о node, быстрой платформе для создания вэб приложений на javascript, обладающей довольно уникальной на сегодняшний день особенностью, неблокирующим I/O (вводом/выводом).

Для начала о nodeJS:

1) В качестве языка используется JavaScript
2) Для выполнения JavaScript используется движок V8 от Google, который работает довольно быстро благодаря компиляции в машинный код перед выполнением.
3) Для реализации неблокирующего I/O используются libev и libeio, (libev показывает более хорошие результаты по сравнению с libevent)
4) Для реализации подключения библиотек выбран синтаксис commonJS
5) Есть возможность писать модули ещё и на C/C++, при этом подключаются они точно так-же как и js модули, это позволит Вам, к примеру, любое узкое место в вашем приложении переписать на C++ без каких либо трудностей.

В процессе изучения данного момента, что в итоге привело к написанию этой статьи я успел довольно неплохо поиграться с этой особоенностью. И могу сказать, что неблокирующий ввод/вывод очень и очень позитивно сказывается на производительности и устойчивости к нагрузкам.

Разрабатываем мы тут некоторый сервис интеграции с очень сторонней системой. Сам сервис работает на Node.js. И всё бы хорошо, но только недоступность сервера во время сборки мусора очень нервировала стороннюю систему.

В канун нового года было решено сделать серверу подарок — обновить Node.js с версии 0.4.8 до 0.6.6 В силу ряда организационных причин, обсуждать которые здесь не очень хочется, обновление было проведено сразу на боевой системе и даже без регрессионного тестирования.

Неужели в этой ситуации что-то могло пойти не так?

Все знакомы с css параметром border, но есть ли вещи, которые мы не знаем о нем?

Много людей знают, что такое getter'ы и setter'ы во многих языках программирования. Есть эти чудесные штуки и в JavaScript, хоть узнал я об этом совсем недавно (темень я необразованная). Речь пойдёт не только и не столько про методы getSomeProperty()/setSomeProperty(...), а про более интересную реализацию — псевдо-аттрибуты, при изменении которых будут вызываться функции-обработчики.

От переводчика: в этой статье нет описания команд git, она подразумевает, что вы уже знакомы с ним. Здесь описывается вполне здравый, на мой взгляд, подход к содержанию публичной истории в чистоте и порядке.

Если вы не понимаете, что побудило сделать git именно таким, то вас ждут страдания. Используя множество флагов (--flag), вы сможете заставить git работать так, как по вашему мнению он должен работать, вместо того, чтобы работать так, как git того хочет. Это как забивать гвозди отверткой. Работа делается, но хуже, медленнее, да и отвертка портится.

Дорогой Хабр, по итогам марта мы выбрали для тебя 10 самых интересных на наш взгляд стартапов, и у каждого из них своя «номинация».

«10» за тщательность

Стартап Fixber — это площадка по предоставлению услуг тестирования сайтов и программного обеспечения, своего рода Head Hunter для тестировщиков. Сервис, который предоставляет Fixber, дешевле и лучше, чем все существующие аналоги, потому что позволяет нанять сразу нескольких тестировщиков по разумной цене. У каждого тестировщика есть портфолио, а заказчики могут оставлять отзывы о проделанной работе, формируя репуацию специалиста.

Отдельная история – это поиск багов. Создатели Fixber говорят: «кто первым найдем баг – тому приз». Естественно, имеется ввиду денежное вознаграждение. И искать баг начинает гарантированно больше, чем один человек, а в деле поиска и устранения мелких «косяков» перед запуском, как известно, количество ищущих очень даже перерастает в качество поиска. И, как следствие, результата.

«10» за наглядность

Стартап Resumup — это приложение для создания инфографического аналога личного резюме или профиля вакансии. Создатели проекта сделали ставку на то, что благодаря наглядности диаграмм и чартов, информация стала гораздо более читабельна.

В центре функционала Resumup — горизонтальный таймлайн, промаркированный годовыми засечками. В остальном — сохранено деление на рубрики классического резюме: зарплатные ожидания (в несовсем привычном виде почасовой ставки) знание иностранных языков, личностные и профессиональные навыки, ценности, увлечения (симпатичными иконками), тип личности. Из особенно интересного: определение типа личности, например, отметкой на шкале «экстраверсия-интроверсия» или «импульсивность-самоконтроль» с бегующим ползунком.

Сейчас много проектов по созданию новых сервисов совместной работы. Несмотря на то что инвесторы уже начали понимать перспективность SaaS-рынка, еще остается определенный скепсис, и если такой стартап приходит к инвестору, то может услышать: «Зачем еще один тысяча первый сервис совместной работы?». Нужно наглядно показать, что рынок растет и готов вместить еще одного игрока. Мы делаем именно такой сервис, и нам пришлось подготовить разумные объяснения.

Инвестор вкладывает в бизнес, рассчитывая на рост капитализации, поэтому нужно быть готовым рассказать про капитализацию рынка. Выяснилось, что инвесторы тоже люди и, как все люди, больше интереса проявляют к интересным историям о том, как развитие продукта и рынка изменят мир.

Если кратко, рынок очень большой, быстро растет и можно без страха на него заходить. Выручка в целом по рынку за 2003 год составила $3b, за 2011 год — $12b. На 2015 год Gartner прогнозирует $21b. Облачные сервисы стоят в 40 раз дороже прибыли, отсюда капитализация рынка получается $840b.

Некоторое время назад я гуглил интернет по поводу “REST vs SOAP”, прочитал пару статей и вроде бы все понял, но не почувствовал от этого никакого удовлетворения. Что-то было не так, то ли я не почувствовал основную идею, то ли просто читал, одновременно слушая новый музон и думая о новой фиче в проекте. Как появилось время, решил восполнить этот пробел, заодно написав полезную статью по этому поводу.