Недавно хорошие знакомые попросили помочь им выбрать систему документооборота со словами «ну ты же занимаешься этой всякой автоматизацией».

Я согласился, хотя и работаю в немного другом направлении и раньше вплотную не сталкивался с СЭД. То что я обнаружил в процессе изучения и сравнения разных решений мне настолько интересным, что я даже решился на небольшое расследование и теперь делюсь результатами.

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

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

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

Этим мы сейчас и займёмся. Копнём на полную глубину и посмотрим, почему так происходит и как в таких условиях вести себя покупателю, чтобы таки увидеть то, что скрыто.

На Хабре очень мало статей, посвящённых неигровым применениям Unity3D. Мы решили исправить эту досадную ситуацию и рассказать о том, как мы делали (и продолжаем делать) онлайн-планировщик квартир (да-да, очередной!) с рендерингом качественных изображений на серверной стороне и интеграцией с Oculus Rift.

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

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

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

И вот, однажды я решил портировать библиотеку на PHP, и теперь хочу поделиться ею с народом и очень надеюсь на помощь в ее улучшении: буду рад советам, баг-репортам и особенно pull-реквестам. Библиотека находится на GitHub'е: github.com/Andre-487/php_rutils

UPD от 26.10.2013: теперь библиотека так же доступна через Composer: packagist.org/packages/andre_487/php_rutils
Так же хочу сказать спасибо всем, кто помог улучшить библиотеку и довести ее до стабильного релиза.

Возможности библиотеки

PHP RUtils — порт Pytils на PHP. Это утилиты для работы с русским текстом. Утилиты разделены на следующие модули (классы):

• Numeral — работа с числами: склонение существительных в зависимости от количества, числа прописью, суммы денег в рублях и копейках прописью.
• Dt — работа с датами: расширение формата дат PHP русскими именами месяцев, дней недели; временные периоды (например, 24 976 дней назад).
• Translit — транслитерация, подготовка строк для использования в URL'ях, именах файлов.
• Typo — небольшой набор правил типографики простого текста.

Предлагаем вашему вниманию очередную подборку с ссылками на новости и материалы.

Приятного чтения!

Вместо предисловия

Я программирую на Yii уже два года и в последнее время начал засматриваться на Symfony Framework 2. Отчасти меня привлекает продуманная архитектура, отчасти слабая связность компонентов, отчасти гибкость построенных приложений. Сразу после того, как я разобрался с основным устройством нового фреймворка, мне стало интересно, возможно ли на нем построить CMS, а может быть, даже воспользоваться готовой.

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

Symfony CMF

Проект Symfony CMF призван упростить разработку функционала, присущего CMS, для всех, кто использует в работе Symfony Framework 2.
Основные особенности проекта:

• слабая связность компонентов
• масштабируемость
• удобство
• тестируемость

Стоит сделать акцент на слове CMF — проект не является CMS сам по себе, это именно фреймворк. В отличие от CMS, где все компоненты жестко завязаны друг на друге, в Symfony CMF вы:

• используете все, что хочется
• заменяете то, что не нравится
• игнорируете то, что не требуется

То есть, вам дан набор модульных инструментов для разработки, а не готовое приложение «под ключ», хотя уже разработаны базовые бандлы, обеспечивающие CMS-функционал.

15 Февраля 2013 года на Урале произошло падения метеорита. На сегоднешний день челябинский метеорит — если не самый известный, то один из известнейших. Не последнюю роль в столь большой известности сыграло невероятное огромное количество фото/видео материала.

Как правило, мнения расходятся касательно того, хорошей ли практикой является использование публичных свойств в PHP классах или всё же стоит использовать геттеры и сеттеры (и хранить свойства приватными или защищёнными). Ещё одно, компромиссное мнение, состоит в том, чтобы использовать магические методы __get() и__set().
У каждого из подходов существуют свои достоинства и недостатки, давайте взглянем на них…

Продолжение истории Скотта Миллера и компании Apogee (3D Realms), начало здесь.

Ключевая идея

Джон Ромеро работал в компании Softdisk, которая в то время занималась изданием ежемесячного журнала, продававшегося в обычных магазинах. В комплекте к журналу шла дискета, на которой было много полезного софта — часть из него разрабатывалась собственными программистами компании, работавшими в редакции. Так вот, Ромеро был как раз одним из них.

После нескольких месяцев, проведенных Миллером за рассылкой Ромеро электронных писем, написанных от имени нескольких вымышленных поклонников творчества Джона, ему наконец-то удалось получить ответ. Двое начали рассуждать на тему, как бы могло выглядеть возможное сотрудничество гейм-дизайнера и Apogee.

«Как жаль, что у меня не сохранились эти письма… Сейчас они, наверное, стоят целое состояние!» — шутит сегодня Миллер.

В первой редакции говорилось о двадцатилетнем баге. На самом деле ему 30 лет. Спасибо Sidnekin.

Сегодня, считывая какие-то данные, моя программа обработала 36'916 возможных дат. Две из этих 36'916 не прошли проверку. Я не придал этому значения, потому что эти даты были из данных предоставленных клиентом, а такие данные часто удивляют. Однако, взглянув на исходные данные, выяснилось, что проверку не прошли 1 января 2011 и 1 января 2007. В программе, написанной мной месяц назад, был баг. Но оказалось, что этому багу 30 лет.

Любому человеку, который не очень понимает экосистему программного обеспечения, написанное ниже покажется странным, но в этом есть смысл. Из-за решения, принятого давным-давно, чтобы принести деньги одной компании, мой $клиент потратил деньги на оплату мне, чтобы я исправил баг, внесённый одной компанией случайно, а другой специально. Чтобы объяснить это, мне придётся рассказать о третьей компании, добавившей особенность, ставшую в конечном счёте багом, и ещё о нескольких фактах, повлиявших на непонятный баг, который я исправил сегодня.

Которые помогут вам оценить и повлиять на состояние ИТ-инфраструктуры вашей организации

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

Вечная головная боль у руководства компании: как организовывать, контролировать и оценивать работу ИТ-службы, ничего не понимая в предметной области? Очень общий совет – обратиться за помощью к внешним консультантам. Но есть ряд простых вопросов, которые позволяют если и не оценить точно, то, как минимум, повлиять на состояние дел в ИТ-инфраструктуре.

Одной из причин слабого использования Linked Data-баз знаний в обычных, ненаучных приложениях является то, что мы не привыкли придумывать юзкейсы, видя перед собой только данные. Трудно спорить с тем, что сейчас в России производится крайне мало взаимосвязанных данных. Однако это не значит, что разработчик, создающий приложение для русскоязычной аудитории совсем уж отрезан от мира семантического веба: кое-что всё-таки у нас есть.

Основными источниками данных для нас являются международные базы знаний, включающие русскоязычный контент: DBpedia, Freebase и Wikidata. В первую очередь это справочные, лингвистические и энциклопедические данные. Каждый раз когда вам в голову приходит мысль распарсить кусочек википедии или викисловаря — ущипните себя как следует и вспомните о том, что всё, что хранится в категориях, инфобоксах или таблицах, уже распарсено и доступно через API с помощью SPARQL или MQL-интерфейса.

Я попробую привести несколько примеров полезных энциклопедических данных, которые вы не найдете нигде, кроме Linked Data.

Эта статья — первая из цикла Базы знаний. Следите за обновлениями.

• Часть 1 — Введение
• Часть 2 — Freebase: делаем запросы к Google Knowledge Graph
• Часть 3 — Dbpedia — ядро мира Linked Data
• Часть 4 — Wikidata — семантическая википедия

Привет Хабра!

Эта статья продолжает цикл статей об игровом движке StalinGrad. В прошлой статье мы насиловали DHTML, а в этой — будем насиловать архитектуру и прототипы.

Кода практически не будет, поэтому, если вы не web разработчик, можете просто почитать про архитектуру и ООП. И таки да — про HTML5 тут снова ничего не будет, только DHTML-хардкор :)



Сразу короткое демо:
Пример 1 — паралельные миры
Пример 2 — один мир с разных камер
Пример 3 — боты
Пример 4 — нянкэт, облака и портальная пушка

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

Несмотря на то, что Эйнштейн не был нейробиологом, он точно знал все, когда говорил о способности человека добиваться чего-либо. Он интуитивно догадывался о том, что лишь сегодня нам удалось подтвердить с помощью данных, а именно: что заставляет когнитивные способности работать на максимально высоком уровне. По существу: То, что тебя не убивает, делает тебя умнее.

(От переводчика: этот текст появился в блоге одного из разработчиков языка Go в новогоднюю ночь 2012. Текст ничуть не утратил актуальности за два минувших года; более того, вместо Go в тексте вполне мог бы стоять любой другой немейнстримовый язык. Собственно, именно об этом текст и повествует.)

Одна моя знакомая актриса — назовём её Эсмеральдой — как-то сказала, «Я всегда знала, что стану актрисой. Даже представить не могу, чтобы я была кем-то ещё!» Кто-то парировал: «Какая же тогда из тебя актриса?»

Я вспомнил об этой беседе, прочитав отзыв о языке Go: «Даже представить не могу, как можно программировать на языке без дженериков!» Мне так и хотелось парировать: «Какой же тогда из тебя программист?»

Эта заметка не о дженериках — против них я ничего не имею: возможно, однажды они в Go появятся, а возможно, нет. Эта заметка о воображении, или по крайней мере о том, что программисты обычно выдают за воображение: претензии. Один мой друг отметил, что самый распространённый ныне способ проводить свободное время — сотрясать воздух Сети своими жалобами. Для жалобщиков это умиротворяющая разрядка; но адресатов неиссякающего потока жалоб это весьма угнетает. На меня жаловались столько, что теперь мне самому стала нужна разрядка. Что я для этого делаю? правильно, пишу возмущённый пост в свой блог.

Доброго времени суток, уважаемые хабравчане. За последнее время я увидел несколько интересных и полезных инструментов/библиотек/событий, которыми хочу поделиться с Хабром.

Stackedit

Шедевр среди Open Source редакторов! Основан на библиотеке разметки (Markdown) PageDown, которая используется в StackOverflow и других проектах StackExchange. Stackedit синхронизируется с Dropbox и Google Drive, а также сохраняет все документы в local storage, благодаря чему редактирование возможно и в онлайне и в оффлайне. Возможность импорта/экспорта/конвертация Markdown и HTML. Публикация в WordPress, Tubmlr, Blogger, Github, Gist и на любой SHH сервер. Статистика, работа в режиме realtime, поддержка различных синтаксисов (Prettify/Highlight.js), LaTeX, темы… Это просто великолепный продукт.


App.io позволяет запускать iOS приложения в браузере. Это уже тема мобильной разработки, но недавно я читал статью про Sprinty Driver и обратил внимание на то, что BeetlePlay разрабатывают демо-версии на Flash. Решил поделиться. Также советую фреймворк для создания анимаций в UIKit от IFTTT.

От переводчика: данный текст даётся с незначительными сокращениями по причине местами излишней «разжёванности» материала. Автор абсолютно справедливо предупреждает, что отдельные темы могут показаться читателю чересчур простыми или общеизвестными. Тем не менее, лично мне этот текст помог упорядочить имеющиеся знания по анализу сложности алгоритмов. Надеюсь, что он окажется полезен и кому-то ещё.
Из-за большого объёма оригинальной статьи я разбила её на части, которых в общей сложности будет четыре.
Я (как всегда) буду крайне признательна за любые замечания в личку по улучшению качества перевода.

Опубликовано ранее:
Часть 1
Часть 2
Часть 3

Оптимальная сортировка

Поздравляю! Теперь вы знаете о том, как анализировать сложность алгоритмов, что такое асимптотическая оценка и нотация «большое-О». Вы также в курсе, как интуитивно выяснить является ли сложностью алгоритма O( 1 ), O( log( n ) ), O( n ), O( n² ) и так далее. Вы знакомы с символами o, O, ω, Ω, Θ и понятием «наихудшего случая». Если вы добрались до этого места, то моя статья уже выполнила свою задачу.

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

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

Как и обещали, сегодня мы ответим на важный вопрос: «Кому поручить производство?». Разберем достоинства и недостатки трех вариантов ответа: использование собственной площадки, подключение контрактных производителей или работа с единым технологическим партнером.

Эта статья задумана мной как сборник некоторых интересных моментов по использованию и оптимизации SQL запросов в БД MySQL, на мой взгляд, плохо освещенных в интернете. Так, из статьи вы узнаете о конструкции with rollup, и о том, как переписать подзапросы in и not in на join'ы, а так же обновление и удаление данных в нескольких таблицах — одним запросом, и многое другое. Начнем по порядку.

От переводчика: данный текст даётся с незначительными сокращениями по причине местами излишней «разжёванности» материала. Автор абсолютно справедливо предупреждает, что отдельные темы покажутся чересчур простыми или общеизвестными. Тем не менее, лично мне этот текст помог упорядочить имеющиеся знания по анализу сложности алгоритмов. Надеюсь, что он будет полезен и кому-то ещё.
Из-за большого объёма оригинальной статьи я разбила её на части, которых в общей сложности будет четыре.
Я (как всегда) буду крайне признательна за любые замечания в личку по улучшению качества перевода.

Введение

Многие современные программисты, пишущие классные и широко распространённые программы, имеют крайне смутное представление о теоретической информатике. Это не мешает им оставаться прекрасными творческими специалистами, и мы благодарны за то, что они создают.

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

Предлагаем вашему вниманию очередную подборку с ссылками на новости и материалы.

Кстати, вчера исполнился ровно год с момента публикации первого PHP-дайджеста на Хабре. Огромное спасибо всем, кто так или иначе помогал создавать дайджесты, спасибо разработчикам за замечательные инструменты, авторам за их полезные статьи, а главное спасибо вам за то, что до сих пор читаете!