Было время, когда я ничего не знал про VCS, ни что это такое, ни тем более зачем это мне. И верхом своих достижений считал папочку с архивами версий. К моменту осознания необходимости системы контроля версий я уже набил шишек и прочувствовал необходимость такого инструмента. Но борландовский аналог CVS меня не впечатлил. У каждого файла свой номер версии. Как мне получить срез определенного релиза я так и не разобрался. А в это время SVN победоносно шла сквозь умы разработчиков. Черт, это было то, чего мне так не хватало. Прочитав доку и начав работать я просто влюбился в нее. Да, были трудности и определенные неудобства, но куда без них.
Так я и работал бы в SVN, но ничего не стоит на месте. В интернете уже потекли тонкие ручейки новостей про Git. Я не кидаюсь за каждой новой технологией, и прошло уже достаточно много времени, пока мне не прожужжали этим Git’ом все мозги. Мне стало любопытно, я вначале присматривался, примерялся, а потом плюнул и начал новый проект на Git. Мучался с ребятами 2 недели, накачал литературы, написал шпаргалку… ничего, привыкли, … а потом меня поперло.

Теперь меня регулярно просят рассказать про Git и что в нем такого. Уже надоело, поэтому этот пост для тех, кто еще сомневается.

Kohana — довольно молодой PHP фреймворк, форк CI, всецело завязанный на ООП. К достоинствам Kohana можно отнести использование всех возможностей PHP5 на 100%, высокую скорость работы, «легковесность» и простоту как использования, так и изучения. Из минусов отчетливо выделяется небольшое комьюнити, как следствие, не шибко качественная документация и небольшое количество модулей и библиотек.

Не так давно своё знакомство с фреймворками я начинал именно с Kohana и, надо сказать, я был удивлен, насколько легко он мне поддался. Думал будет намного сложнее. Но очень сказывалась нехватка документации и примеров кода. Зарывшись в маны и разбор исходников, через некоторое время, я восполнил интересующие меня пробелы относительно Kohana, и поэтому решил написать эту статью, дабы другим хабралюдям, оказавшимся в схожей ситуации не пришлось по ночам не досыпать и лечить головные боли.

Под катом пример доски объявлений, написанный с помощью Kohana, возможно местами он не претендует на рациональность и здравый смысл, но всё-же я надеюсь услышать конструктивную критику.

Статья рассчитана на людей, имеющих понятие об MVC и ООП, но не имевших, либо мало имевших, дело с фреймворками.

Хочу представить Вашему вниманию файловый хостинг для передачи файлов One Day Files. Почему передачи? Потому что для хранения файлов он не предназначен. Файлы хранятся только один день, но доступны на скачивание без ввода капчи или ожидания. Все что Вам нужно сделать это выбрать файл и скопировать ссылки.

Чем мы лучше?

1. У нас нет рекламы
2. Пользователь скачивающий файл не смотрит рекламу и ничего не вводит
3. Возможность загрузить несколько файлов по очереди, каждый из которых может быть до 100Мб
4. Поддержка QR кодов, теперь скачивание файлов с мобильных устройств стало гораздо проще
5. Drag'n'Drop, просто перетащите файлы в зону загрузки

Надеюсь найдутся люди, которым данный сервис покажется удобным, спасибо за внимание.

Хочу представить вашему вниманию легковесный PHP-фреймворк, на который я недавно наткнулся и который сразу же полюбил.

Fat-Free чем-то похож на известный Ruby-фреймворк Sinatra. Автор Fat-Free помешан на минимализме и чистоте кода, что положительно отразилось на этом простом каркасе для разработки самых разнообразных приложений.

Fat-Free состоит из одного файла и весит всего 55KB. При этом фреймворк обладает таким функционалом: специфический и довольно удобный шаблонизатор, гибкое кеширование, автоматическая защита от спама, интегрированные средства для юнит тестов, профайлер кода.

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

Это, также, единственный фреймворк, который защищает Ваше приложение от хотлинкинга и DoS атак.

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

Но, что делать, если только начинаешь? Прежде чем станут обращаться клиенты, могут быть проблемы с тем, что делать целый день. Это идеальное время, чтобы дать о себе знать.

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

Как разработчик, вы сидите на золотой жиле. Вы осознаете это?

Нет, серьезно, на @#$% золотой жиле! Никогда в истории не существовало возможностей так легко создать что-то с нуля, с маленьким или отсутствующим начальным капиталом и маркетинговой моделью, ограниченной только вашим воображением.

Подумайте о крупнейших сайтах, которые вы постоянно посещаете: Facebook, Twitter, Flickr, Foursquare, или даже Google — все они были созданы разработчиками, у которых была лишь идея. Было ли это легко? Черт, нет. Но это могло быть сделано только в наше время. Так, черт побери, почему вы просиживаете день за днем, работая на кого-то?

Введение

Задача о максимальном потоке является классической и имеет множество применений. Напомню постановку проблемы. Дан взвешенный ориентированный граф с неотрицательными весами (пропускными способностями). Выделены две вершины: исток S и сток T такие, что любая другая вершина лежит на пути из S в T. Потоком назовем функцию F: V x V с такими свойствами

1. Ограничение пропускной способности. Поток по ребру не может быть больше его (ребра) пропускной способности.
2. Антисимметричность. Для каждого ребра (u, v): F(u, v) = -F(v, u).
3. Сохранение потока. Для каждой вершины (кроме S и T), количество входящего потока (отрицательного) равен количеству исходящего потока (положительного). Тоесть, алгебраическая сумма потоков для каждой вершины (кроме S и T) равна нулю.

В этом посте вы можете ознакомиться с реализацией поставленной проблемы.

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

В процессе работы, я как-то набрел на проект phpMyEdit — web-интерфейс, позволяющий относительно просто поднимать админки для табличных данных.

После доработки для себя, родилось решение, которое я назвал QuickAdm. Оно делает за очень короткие сроки админки через web-интерфейс к таблицам, имеет простейшую ACL и защиту паролем.

Таблицы называются объектами, их поля — свойствами. Имя объекта/свойства равно имени таблицы и поля в MySQL, поэтому вводить нужно латиницей.

Потестить это можно тут: http://yamozg.ru/adm (логин/пароль для чтения reader/reader, админские admin/admin — удаление таблиц там не работает, ибо запрещено на уровне БД).

Скачать вот тут: http://yamozg.ru/quickadm.tar.gz (настроить нужно config.php и выполнить quickadm.sql в нужной базе, приложение расчитано на работу в папке /adm/ относительно корня сайта).

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

Я довольно долго откладывал этот анонс, однако сейчас настало его время.

Встречайте: node-mysql-libmysqlclient v0.0.7, коннектор к MySQL для Node.js, поддерживающий синхронное и асинхронное выполнение запросов к БД и имеющий API, близкое к API аналогичных коннекторов для PHP/Perl/Ruby etc.

Целый год позади. Даже не верится, что так быстро пролетело время. Мы решили подвести итог нашей работы, вспомнить что было, что хотели сделать, и каким проект стал сейчас. Ведь 1 год – это не так уж и мало. Плюс мы приготовили для вас подарки!

Преамбула

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

Не нужно обладать сверх-эрудицией для того, чтобы понять смысл двух простых английских слов. Tip — помощь, совет; Meet — встреча. Таким образом можно понять смысл нашего названия, TipMeet это не просто сайт, позволяющий бесплатно общаться в сети, но и консультационная платформа, о которой речь и пойдет.

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

Good news, everyone! Теперь из дома можно не выходить. Ни тем, кто ищет себе учителя, или человека, обладающего уникальными знаниями и опытом, ни последним. Сегодня мы официально ставим на рельсы наш “Личный сервис”, дающий возможность любому человеку организовать свой консультационный офис онлайн.

Сегодня мне кинули ссылку на прикольный сервис для быстрого генерирования изображений-заглушек. Может пригодиться для html-верстки. На мой взгляд, это удобно тем, кто и так использует заглушки — экономит время при вёрстке, т.к. сами заглушки уже готовы. Можно цвета/размеры подбирать, меняя только числа/буквы в коде, не отвлекаясь на сам файл картинки — и сразу видеть эффект. И сами размеры видеть написанными, если нужно, чтоб к коду не возвращаться для проверки. Или вместо размеров можно текст добавить, чтоб всегда знать, для чего эта заглушка (типа «Бан(н)ер» или там «Лого», или «Фотография»).

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

<img src="http://placehold.it/350x50" />

и получаете:


Update. Благодаря усилиям k0rv1n, найден вариант этого сервиса, только лучше :)
Во-первых, там поддерживается кириллица. Во-вторых, там даны ссылки на исходники для разных языков.
Автор dummyimage.com — тот же Russell Heimlich, что и у placehold.it. У placehold.it есть ещё один автор, но будем считать, что он делал дизайн (дизайн там правда круче, но видимо как раз из-за понтового шрифта Unicode и не выходил).

Примеры (см. под хабракатом) я поменял с placehold.it на dummyimage.com, раз уж он функциональнее…

Что такое CouchDB для вас? Вероятно любой, кто хоть немного интересуется популярной нынче темой NoSQL, прекрасно знает общие детали: это такая симпатичная игрушка с map/reduce-запросами, которые пишутся на JavaScript, с которой можно работать, гоняя JSON по HTTP-протоколу, а также не исключено, что слышали, что она fault-tolerant, тобишь не ломается вообще. Дальше этого обычно дело не идёт, в результате CouchDB отправляется в delicious в общую кучу со всякими MongoDB, Cassandra, Hadoop и т.п.

Примерно такого мнения придерживался и я вплоть до недавнего времени, пока не возникла острая необходимость переосмыслить архитектуру текущего проекта (упёршегося лбом в свою реляционную БД) и пересесть на документную базу данных, которая бы умела map/reduce. После того, как более пристально взгялнул на CouchDB, я понял, что он уникален в своём классе, его не следует ставить в один ряд с упомянутыми продуктами. Идеи, которые заложены в CouchDB настолько концептуальны, что способны в корне перевернуть представление о разработке веб-приложений.

О том, что же меня так впечатлило, постараюсь рассказать под катом.

Оригинал статьи на BusinessInsider.com
Dave McClure

Секрет успеха для стартапов: инвестируйте ДО принятия продукта рынком, удваивайте ставки ПОСЛЕ

Прошу прощения… статья получилась длинной (~2500 слов). Не для слабонервных. Если вы хотите сокращенную версию, прочтите нижеследующее резюме и 3 основных утверждения, затем сразу перейдите к выводам вконце.

Резюме: Венчурные фонды становятся меньше (это хорошо), позиции ангельских инвесторов укрепляются (тоже хорошо), но обоим необходимо становиться умнее и инновационнее. Стоимость запуска стартапов значительно снизилась за последние 5-10 лет, а онлайновые каналы дистрибуции через Поиск, Социальные сети, Мобильные платформы (тоесть Google, Facebook, Apple) стали господствовать. В то же время, количество сделок по покупке компаний выросло, но размеры их уменьшились, так как состоявшиеся компании теперь покупают стартапы на более ранних стадиях их жизненного цикла.

Что всё это значит? Какие перспективы и подводные камни это сулит инвесторам?

Давайте начнём с 2 начальных наблюдений текущего рынка для инвесторов и для стартапов.

Я думаю все знают про Google Apps. Это великолепный сервис для организации почты и коллективной работы в рамках компании. Однако у него есть пара маленьких таких недостатков: он предоставляется as is во-первых, и вся ваша корпоративная документация, почта и переписка при использовании Google Apps будут храниться на серверах Google.

В итоге чаще всего серьёзные фирмы выбирают сложный путь — поддерживать все необходимые сервисы на собственных серверах. Этот путь, конечно, даёт массу преимуществ. Системный администратор компании сможет настроить что угодно и как угодно. Однако есть и один существенный недостаток: если у Google всё уже настроено и связано воедино, то вам придётся настраивать всё вручную. Плюс вы вряд ли сможете обеспечить вашу систему таким же красивым и удобным веб-интерфейсом.

Однако, как показывает практика, развернуть гибкую и мощную инфраструктуру для компании можно легко и не прибегая к помощи Google. Под катом я расскажу как интегрировать XMPP сервер с почтовой системой, чтобы получилось в итоге значительно лучше, чем у Google.

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

Уверен, что если есть сервисы которые укорачивают ссылки, то должны были быть и те, которые удлиняют. Т.е. очень важно чтобы был соблюден баланс урлоизменяющих сервисов в природе. Последние были легко найдены: это и HugeUrl, и TitanUrl, и FreakingHugeUrl, и другие… Но что может более бесполезным, чем попытка сделать ненужную вещь лучше. Совершенного удлинителя я не нашел, один использует флэш, другой делает урлы не работающие в IE, третий делает слишком короткие урлы.
Поэтому прошу любить и жаловать мое видение сервиса делающего урлы бессмысленно длинными.

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

Начало материала

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

Линейный конвейер. Путь из точки А в точку Б.
С раннего детства наш мир упорядочен, все примеры, которые нам подкидывает жизнь, родители, школа, сугубо линейны. Исключения редки, воспринимаются как нечто выбивающиеся из правил. Помните, школьные задачки про путь из пункта А в пункт Б, в которых еще встречались промежуточные точки. Это ключевой алгоритм всех действий, которым обучают в обычной, среднестатистической школе. Мы с детства знаем, что для достижения результата, надо сделать то-то и то-то. В этом нет ничего плохого, ведь линейность действий проста, понятна, предсказуема. Вот только есть небольшая проблема, не всегда линейные действия и поведение наиболее эффективно в реальной жизни.

Что я понимаю под правильной обработкой:

• Универсальное решение, которое можно вставить в любой существующий код;
• Легко расширяемое решение;
• В PHP аж три «механизма ошибок»: собственно ошибки (error), исключения (exception) и утверждения (assertion). Свести три механизма к одному — exception. В комментариях к предыдущей статье на эту тему выражалось мнение, что exception это плохой и/или сложный метод обработки ошибок. Я так не считаю и готов это обсудить в комментариях;
• Опциональное логирование;
• Общий обработчик exception, который будет поддерживать разные форматы вывода и debug/production режимы;
• В debug режиме должен выводится trace. Требования к trace: компактный, понятный и по возможности ссылки на открытие файлов в IDE.

Каждый, кому приходилось писать объемные куски осмысленного кода на javascript, рано или поздно понимал, что ему многого не хватает в этом языке или просто неудобны некоторые врожденные конструкции. Для сглаживания шероховатостей применяются jQuery, Prototype, MooTools etc. Кто-то уже мало представляет себе, как можно кодить без них. Сегодня я расскажу о еще одной маааленькой библиотечке, которая делает мир javascript-программиста еще прекраснее. Речь пойдет о Underscore.js