Сегодня обновил свой персональный сайт, убрав все не нужное (как я считаю). Смотрите, оценивайте, пишите свои комментарии.
В общем новая версия http://antonfin.kiev.ua
Кстати, а чьи персональные страницы Вам нравятся больше всего?
С ув. antonfin
Читать дельше...
воскресенье, 22 января 2012 г.
вторник, 24 мая 2011 г.
Скрывать или не скрывать, вот в чем вопрос
Недавно в твитере было обсуждения одного из щепетильных вопросов, который возникает в IT компаниях: "скрывать или не скрывать заработную плату сотрудников".
Варианты возможных решений я выделил таким образом:
1. Однозначно скрывать. Запрещая даже разглашение сотрудниками своих ЗП, под угрозой увольнения.
2. Публичное установление заработных плат. Когда на ту или иную должность установлен норматив оплаты, который известен всем. Если есть доплаты, то они тоже устанавливаются открыто.
3. Предприятие скрывает заработные платы, но не налагает никаких запретов на оглашение, все по желанию сотрудников.
Я попытаюсь рассмотреть позитивные и негативные моменты связанные с первым методом установления ЗП.
Рассмотрим ситуацию, когда компания проводит жесткую политику по отношению к неразглашению ЗП. Чаще такой подход практикуется в компаниях с иностранным (западным) капиталом.
Объясняется данный метод вполне логично, так или иначе оценить it-шника тяжело, вот как сторговались, так и сторговались, если всех все устраивает, то все отлично.
Я не знаю какая у тебя зарплата, ты не знаешь какая у меня, и все находятся в неком блаженном неведении, до поры до времени, пока кто-то что-то не узнал.
История:
Однажды, Вова признался Сережи, что у него 2,5 у.е. ЗП, а Сергей, как-то даже постеснялся признаться, что у него всего 2,2 у.е. ЗП.
Почему постеснялся? Да, потому что все знают, что Сергей, "педалит" в два раза больше, и опыта у него на 3 года больше по отрасли, и на пол года раньше он в компанию пришел.
Вот так, или лоханулся, или в тот момент не нужны были такие специалисты? Кто уж вспомнит.
А когда Вова пришел, то как раз новый проект от иностранного заказчика получили, и второпях команду собирали, плюс как раз рынок был раскочегарен, и никто на зарплату в 2.2 у.е. идти не хотел, а спецы нужны были хоть "всрись". Вот у Вовы и "прокатило" у руководства выторговать чуть больше.
Понимали в руководстве, что Сережа лучше Вовы, и что получать он должен больше, но какой экономический смысл ему прям сейчас поднимать? Сережа и так "лупашит будь здоров!", Вове тоже ЗП не уменьшишь, ведь "вонизма" потом не оберешься.
Так и работают!
Но вот Сережа узнал, и.... Да! Начала Сережу кушать толстая жаба, и вот он уже не рвет булки, притих на собраниях, и все ему как-то пох...й, и каждые 2 месяц он по новым собеседованиям ходит, получше место ищет, или оффер покруче, чтобы у родного руководства побольше ЗП выторговать, и не просто побольше, а так чтобы наказать этих
Стоп... Реальная ситуация?
Вполне. Согласитесь, даже если бы у Сережи ЗП будет на 100у.е. выше, а работает он всего в полтора раза лучше, то скорее всего ему будет не совсем комфортно, ведь он круче, а доплата маленькая.
Давайте разберемся почему так происходит.
Природа данного метода построена на сокрытии реальной ситуации в компании при работе с персоналом, а иначе вы не получите экономических эффектов от ее использования.
Плюсы от использования:
1. Гибкость. Выигрывает от этого подхода компания, так как она получает маневренность при найме новых сотрудников, ведь не имеет значения кто и сколько уже зарабатывает, мы можем хоть в два раза переплатить, все равно об этом никто никогда не должен узнать. Можно не реагировать на растущие тенденции в ЗП. Можно дать не заслуженную надбавку сотруднику, если он собирается уходить, только из-за того, что нужно быстрее закончить проект.
2. Экономия. Нужно помнить, что зарплаты не так уж эластичны к экономическому росту (или к тенденциям на рынке), о их изменениях мы узнаем от людей, с которыми мы можем сравнить свой труд (наилучшим примером для сравнения являются наши коллеги в компании, так как коллеги из других контор могут иметь совершенно иную сферу деятельности), а если в компании запрещено говорить на эту тему, то считайте, что в какой-то момент у вас зарплата станет ниже, чем по рынку, и чем дольше вы в неведении, тем больше экономия.
Минусы. Есть 2 минуса, которые, как мне кажется, больше связаны с нашим менталитетом.
1. Мнимость тайны. Наш человек, более "социален", мы чаще общаемся с коллегами, чаще дружим, отдыхаем, отмечаем праздники. И эта социализация имеет духовную основу, а не партнерскую, как в странах загнивающего капитализма ("Чтоб я так жил"). Поэтому риск того, что мы будем знать кто сколько зарабатывает, несомненно выше.
2. Развитое чувство несправедливости. В наших ценностях не последнее место занимает понятие "правды" (обратите внимания слово правда, в глубоком его понимании, нет в других языках, "правда" - это не только истина, и не только закон, это что-то выше). Так вот рассмотренный случай с Сергеем, это как раз надругательство, над этим положением. У него возникнет чувство несПРАВедливости. Скорее всего этот прекрасный сотрудник будет навсегда потерян для своей компании, если узнает, что ему явно недоплачивали.
Вот такие плюсы и минусы. Конечно при правильном управлении персоналом, можно минимизировать риски минусов (если про них не забывать). Так же с учетом, того что этот метод больше применяется у иноземцев, а ЗП там выше, чем по рынку, то все, как правило, всегда довольны.
В общем, дорогие управленцы, "скрывать или не скрывать" решать вам, но помните, от ваших решений зависит атмосфера в коллективе, а значит и конечный результат.
P.S. Есть еще одна категория людей, которая выигрывает от такого подхода, это пронырливые сотрудники, которые получают немного выше, чем в среднем по компании, но при этом у них отдача ниже. Как правило они молчат (так как их-то за разглашения уволят сразу же).
P.S.S. Граждане читающие, а вы как считаете скрывать или не скрывать?
Читать дельше...
вторник, 19 апреля 2011 г.
Поиск по файлам в Vim
Выдалось немного времени, решил написать, как удобно организовать поиск по файлам в vim.
Скажу стразе, что в vim есть 2 функции, которые позволяют совершить поиск по файлам grep - выводит результат поиска в консоль, а vimgrep выводит результат поиска в командную строку vim.
Читайте: help vimgrep и help grep
Но любители монструозных IDE могут упрекнуть, что мол часто нужно вывести результат в какое-то окошечко и оперативно просматривая результаты открывать/закрывать файлы с нужным нам контентом.
Но vim был бы не vim, если бы там чего-то нельзя было сделать. Итак мой пример организации поиска по файлам в vim.
Для организации поиска по файлам я использую плагин grep.vim (автор Yegappan Lakshmanan) Данный плагин позволяет удобно делать поиск и работать с результатами поиска.
Кладем grep.vim в папку $VIM_HOME/plugin/
Данный плагин использует утилиту grep. Для пользователей Windows автор предусмотрел переменную Grep_Path
:let Grep_Path = 'с:\progs\grep.exe'
У Вас появятся целая куча новых функций для работы с поиском: :Grep, :GrepAdd, :Rgrep, :RgrepAdd, :GrepBuffer, ... Тут очень детально все описано http://www.vim.org/scripts/script.php?script_id=311.
Опишу лишь то, что чаще всего использую я.
Rgrep - рекурсивный поиск по файлам
RgrepAdd - добавляет результат поиска к результатам предыдущего поиска
GrepBuffer - поиск по всем открытым буфферам
Так же удобно забиндить какую-нибудь клавишу для поиска, я, например, использую F2 и F3.
Для этого открываем vimrc и добавляем такой код:
" F2 - Run recursive grep nnoremap <silent> <F2> :Rgrep<cr> " Shift-F2 - Same as ":Rgrep" but adds the results to the current results nnoremap <silent> <S-F2> :RgrepAdd<cr> " F3 - Search for a pattern on all open buffers nnoremap <silent> <F3> :GrepBuffer<cr>
Все, теперь, если Вам нужно найти что-то, просто нажимаем F2 вводим паттерн, по котором нужно осуществить поиск (по умолчанию предлагается текст под курсором), нажимаем Enter, вводим путь к файлам, в которых будет происходить поиск, Enter.
В отдельном окошке появляется список строк, в котором находиться запрашиваемый Вами текст.
Чтобы открыть нужный нам фрагмент, наводим на него курсор и нажимаем Enter.
Вот и все. В лучших традициях, так сказать, жирных IDE.
Пожелание: если есть интересные задачи в vim, которые Вам не удалось самостоятельно решить, или Вы считаете, что vim такое не может, то пишите в комменты, я постараюсь найти варианты решения. За ранее благодарен.
С ув. antonfin
Читать дельше...
воскресенье, 17 апреля 2011 г.
Thanks to Paul Allen...
У меня произошла некоторая проблема при работе с одним проектом.
Я использовал модуль GD::SecurityImage при создании каптчи. Модуль удобный тем, что может использовать разные библиотеки в бекграунде, по умочанию, естественно, GD.
Чисто для справки, мне больше нравиться использовать Image::Magick, но вот не могу подружить данную замечательную библиотеку с одним сервером на freebsd.
В общем стала задача при определенных условиях изменять размеры картинкам. Для чего был использован замечательный модуль Image::Resize.
Каково было мое удивление, когда мне утром позвонил заказчик с жалобой что все каптчи стали выдаваться с черным бекграундом. :(
Новость была паршивая, так как модуль для работы с каптчами я не трогал. При ее создании было установлен параметр bgcolor как [255,255,255], то есть явно белый. Работа с графикой в принципе поменялась лишь благодаря добавлению ресайзу картинок. Причем картинки, это были часть контента сайта, и с каптчей ни каким образом не пересекались.
С начала логически, а потом экспериментально,, было выявлено, что каптча меняет бекграунд при добавлении строки 'use Image::Resize;'. Модуль где происходил ресайз и модуль для генерации капчи друг-друга не вызывали, то есть возможный ре-импорт какой-либо функции я откинул (Но оба модуля вызывались одним fcgi скриптом).
Значит вызов Image::Resize, чего-то менял в окружении или в логике работы самой GD.
perldoc -m Image::Resize;
Жму v.
Открывается vim c кодом модуля Image::Resize.
10-11 строчки
# Thanks to Paul Allen for this tip
GD::Image->trueColor( 1 );
Что за нафиг?
perldoc GD
Ищу метод trueColor. Пишут такое:
For backwards compatibility with scripts previous versions of GD, new images created from scratch (width, height) are palette based by default. To change this default to create true color images use:
GD::Image->trueColor(1);
somewhere before creating new images. To switch back to palette based by default, use:
GD::Image->trueColor(0);
Ну что же. Можно попробовать изменить.
Добавляю у себя перед созданием каптчи GD::Image->trueColor(0).
И у меня создается каптча с белым бекграудом! Ура! То что нужно!
Вот так фикс Пола Аллена испортила мне воскресный вечер. Thanks to Paul Allen....
Если кто-то знает в чем была проблема, зачем нужно использовать trueColor и почему могла возникнуть такая бага пишите в комменты. Если ответа не поступит обещаю в последующих постах раскрыть тему глубже.
С ув. antonfin.
Читать дельше...
Я использовал модуль GD::SecurityImage при создании каптчи. Модуль удобный тем, что может использовать разные библиотеки в бекграунде, по умочанию, естественно, GD.
Чисто для справки, мне больше нравиться использовать Image::Magick, но вот не могу подружить данную замечательную библиотеку с одним сервером на freebsd.
В общем стала задача при определенных условиях изменять размеры картинкам. Для чего был использован замечательный модуль Image::Resize.
Каково было мое удивление, когда мне утром позвонил заказчик с жалобой что все каптчи стали выдаваться с черным бекграундом. :(
Новость была паршивая, так как модуль для работы с каптчами я не трогал. При ее создании было установлен параметр bgcolor как [255,255,255], то есть явно белый. Работа с графикой в принципе поменялась лишь благодаря добавлению ресайзу картинок. Причем картинки, это были часть контента сайта, и с каптчей ни каким образом не пересекались.
С начала логически, а потом экспериментально,, было выявлено, что каптча меняет бекграунд при добавлении строки 'use Image::Resize;'. Модуль где происходил ресайз и модуль для генерации капчи друг-друга не вызывали, то есть возможный ре-импорт какой-либо функции я откинул (Но оба модуля вызывались одним fcgi скриптом).
Значит вызов Image::Resize, чего-то менял в окружении или в логике работы самой GD.
perldoc -m Image::Resize;
Жму v.
Открывается vim c кодом модуля Image::Resize.
10-11 строчки
# Thanks to Paul Allen
GD::Image->trueColor( 1 );
Что за нафиг?
perldoc GD
Ищу метод trueColor. Пишут такое:
For backwards compatibility with scripts previous versions of GD, new images created from scratch (width, height) are palette based by default. To change this default to create true color images use:
GD::Image->trueColor(1);
somewhere before creating new images. To switch back to palette based by default, use:
GD::Image->trueColor(0);
Ну что же. Можно попробовать изменить.
Добавляю у себя перед созданием каптчи GD::Image->trueColor(0).
И у меня создается каптча с белым бекграудом! Ура! То что нужно!
Вот так фикс Пола Аллена испортила мне воскресный вечер. Thanks to Paul Allen....
Если кто-то знает в чем была проблема, зачем нужно использовать trueColor и почему могла возникнуть такая бага пишите в комменты. Если ответа не поступит обещаю в последующих постах раскрыть тему глубже.
С ув. antonfin.
Читать дельше...
понедельник, 11 апреля 2011 г.
Маркетинг vs Разработки
Не знаю на сколько адекватна тема топика, тому что будет изложено ниже. Так или иначе хочу поделиться вот такими мыслями.
Время-от-времени я слышу от наших отечественных интернет-деятелей (бизнесмены, разработчики, стартаперы, CEO-шники и прочие) о том, что вот есть желание реализовать Web-систему, которая будет выдерживать высокие нагрузки, для этого ищу организацию, которая бы могла данный проект реализовать. И сразу сыпятся предложения от более-менее крупных Web-студий, что вот мы классные дядьки и готовы взяться, и вот такое у нас портфолио (банки, страховые компании, сайты торговых марок и т.д.), и мы и тем делали, и этим!
Но при детальном изучении портфолио понимаешь, что половина реализованных проектов имеют столько общего с высоконагруженными системами сколько персональный сайт Сысоева с Web дизайном.
Ну, предположим, реализовали они какой-то крупной финансовой группе Web-сайт. Ну что, кто-то считает что там больше 20-50 тис. хостов в неделю? Ну вспомните, когда Вы последний раз заходили на сайт банка, в котором храните деньги. Я один раз, в жизни зашел, чтобы посмотреть телефон поддержки.
Или вот сайт популярного футбольного клуба. Да сайт красивый, там про футболистов, интервью, но какую нагрузку он создает? Да и чем он нагружать может? Разве что контентом, но тут работы на пол дня для толкового системного администратора.
Еще есть сайты для популярных учебных заведений, торговых марок, сайты поп-групп и еще очень много барахла.
Но вот в чем суть-то. Все эти сайты из портфолио они имеют больше маркетинговую ценность для Web-студии, 90% знают компанию "Бла-бла-бла Банк" (выдумал), и если Вы/Ваша студия писала им сайт, то средний обыватель подумает: "Ну, это круто! Все знают банк "Бла-бла-бла Банк", и все знают facebook и google, значит эта студия сможет реализовать любой проект, будь-то Социальная сеть, или Мега-портал, или файловый хостинг".
А знаете, что парадоксально. Они действительно могут...
Нет, нет, они реализуют Вам прекрасную соц.сеть, которая с легкостью выдержит 10-15 тис. хостов в день (это где-то 1000 пользователей) (НО заплатите Вы, конечно, как за клон facebook-а).
Вы запуститесь, а дальше...
70% - не наберут и 250 постоянных пользователей, через год закроются, так как финансировать такое мероприятие, затея не из дешевых.
20-25% - смогут дотянуть до 500-700 постоянных пользователей и тоже закроются.
3-4% - скорее всего сумеют втюхать данный проект какому-нибудь инвестору и радоваться жизни, проект скорее всего загнется, если инвестор не наймет толковую команду, которая потихоньку все перепишет.
У остальных, естественно, возникнут проблемы с нагрузками, но к тому времени уже пройдет год-два как Вы запустились, и Вы решите просто проапгрейдить железо и Вам этого хватит еще на полгода-год. А через 3 года, когда будет тяжко, Вы уже не пойдете к той мега-популярной Web-студии, так как много воды утечет. Да и за 3 года столько всего поменяется. Web на месте не стоит. А может появиться понимание того, что такое высокие нагрузки.
Подумайте, кто работает в Web-студиях на должности программистов? Зачем студии держать толкового perl-программиста со знаниями c, или гуру unix систем, или профессионального js-разработчика? Ведь 90% задач сводиться к написанию визитки или интернет-магазина на базе какой-нибудь CMS, где важен дизайн и CEO-оптимизация.
Какая репликация, какой шардинг, какой Memcached, какие нереляционные БД? Зачем?!?
Тут все сводится к вопросу нужно ли использовать для визитки шаблонизатор.
Нет. конечно есть Web-студии, которые реализую серьезные проекты, но как правило они ориентированы на иностранного заказчика (рынок слишком узкий), реализовав для них 2-3 действительно серьезных проекта, и продолжая из поддержку, но они не вешаются на первый попавшийся проект тем более от отечественных заказчиков.
Кстати, я не представляю высоко-нагруженного проекта без поддержки. Нагрузки постоянно изменяются, постоянно выплывают "узкие места", которые нужно ликвидировать, причем их просто невозможно спрогнозировать. Количество серверов растет, взаимодействие между ними усложняется, проект постоянно в динамике.
Представьте высоконагруженную систему без поддержки:
Мне надо опимизировать БД, я иду в Web-студию и говорю, у меня проблема с БД. Стоп... Не так...
Сайт начинает очень медленно работать. Вы идете в Web-студию и говорите сайт медленно работает, что делать? Они говорят:
- N-килобаксов и мы в течении 3-5 дней ищем и устраняем проблемы.
- Еб.. 3-5 дней! От меня пользователи разбегутся! Мне надо сейчас!
- К сожалению мы не можем прям сейчас, разработчик(и), который писал(и) Ваш сайт ушли/умерли/в отпуске/в отгуле/верстаю срочно кому-то визитки.
Вы с матюгами:
- 2*N-килобаксов!
- Секундочку! (деньги делают чудо). Сережа посмотри, что там с сайтом товарища.
Какой-то непонятный Сережа мыкается 2 часа по сайту и выдает: "Проблема с БД. Надо оптимизировать! Как?!? Сервер БД уже давным-давно на отдельной мега-машине!?! Ну давайте попробуем Memcached. Но у Вас код не заточен, чтобы его использовать, поэтому нам надо 2 недели, чтобы все переписать (кто не знает, но на практике через 2 недели никогда ничего не бывает). И Вы понимаете, что дешевле было держать 2-3 Сереж-программистов у себя в офисе полгода, чем решить эту проблему с БД. А пользователи тем временем бегут с Вашего сайта, потому что он превратился в унылое медленно "Г".
Маркетинг сила, часто на одном только словоблудии и красивых картинках можно получить проекты рассчитанные на высокие нагрузки, но будет ли это рабочим вариантом не так уже и важно. Почему? Для заказчика, потому что он ничего не понимает, для Web-студии, так как только 1 из 100 проектов действительно станут популярными в сети.
В общем парадоксальная ситуация в разработке серьезных проектов "КАЧЕСТВО ПРОГРАММНОЙ ЧАСТИ" часто имеет меньшее значение, чем дизайн, ceo или promotion. Как Вам такой вывод?
С ув. antonfin.
Время-от-времени я слышу от наших отечественных интернет-деятелей (бизнесмены, разработчики, стартаперы, CEO-шники и прочие) о том, что вот есть желание реализовать Web-систему, которая будет выдерживать высокие нагрузки, для этого ищу организацию, которая бы могла данный проект реализовать. И сразу сыпятся предложения от более-менее крупных Web-студий, что вот мы классные дядьки и готовы взяться, и вот такое у нас портфолио (банки, страховые компании, сайты торговых марок и т.д.), и мы и тем делали, и этим!
Но при детальном изучении портфолио понимаешь, что половина реализованных проектов имеют столько общего с высоконагруженными системами сколько персональный сайт Сысоева с Web дизайном.
Ну, предположим, реализовали они какой-то крупной финансовой группе Web-сайт. Ну что, кто-то считает что там больше 20-50 тис. хостов в неделю? Ну вспомните, когда Вы последний раз заходили на сайт банка, в котором храните деньги. Я один раз, в жизни зашел, чтобы посмотреть телефон поддержки.
Или вот сайт популярного футбольного клуба. Да сайт красивый, там про футболистов, интервью, но какую нагрузку он создает? Да и чем он нагружать может? Разве что контентом, но тут работы на пол дня для толкового системного администратора.
Еще есть сайты для популярных учебных заведений, торговых марок, сайты поп-групп и еще очень много барахла.
Но вот в чем суть-то. Все эти сайты из портфолио они имеют больше маркетинговую ценность для Web-студии, 90% знают компанию "Бла-бла-бла Банк" (выдумал), и если Вы/Ваша студия писала им сайт, то средний обыватель подумает: "Ну, это круто! Все знают банк "Бла-бла-бла Банк", и все знают facebook и google, значит эта студия сможет реализовать любой проект, будь-то Социальная сеть, или Мега-портал, или файловый хостинг".
А знаете, что парадоксально. Они действительно могут...
Нет, нет, они реализуют Вам прекрасную соц.сеть, которая с легкостью выдержит 10-15 тис. хостов в день (это где-то 1000 пользователей) (НО заплатите Вы, конечно, как за клон facebook-а).
Вы запуститесь, а дальше...
70% - не наберут и 250 постоянных пользователей, через год закроются, так как финансировать такое мероприятие, затея не из дешевых.
20-25% - смогут дотянуть до 500-700 постоянных пользователей и тоже закроются.
3-4% - скорее всего сумеют втюхать данный проект какому-нибудь инвестору и радоваться жизни, проект скорее всего загнется, если инвестор не наймет толковую команду, которая потихоньку все перепишет.
У остальных, естественно, возникнут проблемы с нагрузками, но к тому времени уже пройдет год-два как Вы запустились, и Вы решите просто проапгрейдить железо и Вам этого хватит еще на полгода-год. А через 3 года, когда будет тяжко, Вы уже не пойдете к той мега-популярной Web-студии, так как много воды утечет. Да и за 3 года столько всего поменяется. Web на месте не стоит. А может появиться понимание того, что такое высокие нагрузки.
Подумайте, кто работает в Web-студиях на должности программистов? Зачем студии держать толкового perl-программиста со знаниями c, или гуру unix систем, или профессионального js-разработчика? Ведь 90% задач сводиться к написанию визитки или интернет-магазина на базе какой-нибудь CMS, где важен дизайн и CEO-оптимизация.
Какая репликация, какой шардинг, какой Memcached, какие нереляционные БД? Зачем?!?
Тут все сводится к вопросу нужно ли использовать для визитки шаблонизатор.
Нет. конечно есть Web-студии, которые реализую серьезные проекты, но как правило они ориентированы на иностранного заказчика (рынок слишком узкий), реализовав для них 2-3 действительно серьезных проекта, и продолжая из поддержку, но они не вешаются на первый попавшийся проект тем более от отечественных заказчиков.
Кстати, я не представляю высоко-нагруженного проекта без поддержки. Нагрузки постоянно изменяются, постоянно выплывают "узкие места", которые нужно ликвидировать, причем их просто невозможно спрогнозировать. Количество серверов растет, взаимодействие между ними усложняется, проект постоянно в динамике.
Представьте высоконагруженную систему без поддержки:
Мне надо опимизировать БД, я иду в Web-студию и говорю, у меня проблема с БД. Стоп... Не так...
Сайт начинает очень медленно работать. Вы идете в Web-студию и говорите сайт медленно работает, что делать? Они говорят:
- N-килобаксов и мы в течении 3-5 дней ищем и устраняем проблемы.
- Еб.. 3-5 дней! От меня пользователи разбегутся! Мне надо сейчас!
- К сожалению мы не можем прям сейчас, разработчик(и), который писал(и) Ваш сайт ушли/умерли/в отпуске/в отгуле/верстаю срочно кому-то визитки.
Вы с матюгами:
- 2*N-килобаксов!
- Секундочку! (деньги делают чудо). Сережа посмотри, что там с сайтом товарища.
Какой-то непонятный Сережа мыкается 2 часа по сайту и выдает: "Проблема с БД. Надо оптимизировать! Как?!? Сервер БД уже давным-давно на отдельной мега-машине!?! Ну давайте попробуем Memcached. Но у Вас код не заточен, чтобы его использовать, поэтому нам надо 2 недели, чтобы все переписать (кто не знает, но на практике через 2 недели никогда ничего не бывает). И Вы понимаете, что дешевле было держать 2-3 Сереж-программистов у себя в офисе полгода, чем решить эту проблему с БД. А пользователи тем временем бегут с Вашего сайта, потому что он превратился в унылое медленно "Г".
Маркетинг сила, часто на одном только словоблудии и красивых картинках можно получить проекты рассчитанные на высокие нагрузки, но будет ли это рабочим вариантом не так уже и важно. Почему? Для заказчика, потому что он ничего не понимает, для Web-студии, так как только 1 из 100 проектов действительно станут популярными в сети.
В общем парадоксальная ситуация в разработке серьезных проектов "КАЧЕСТВО ПРОГРАММНОЙ ЧАСТИ" часто имеет меньшее значение, чем дизайн, ceo или promotion. Как Вам такой вывод?
С ув. antonfin.
Читать дельше...
понедельник, 4 апреля 2011 г.
Вышел очередной perl podcast
1 апреля был анонсирован новый YAPP #2: Новости за прошедший месяц, источники информации на русском, новые cpan модули за 01.03.2011 - 01.04.2011.
Начиная с пилотного выпуска слышу много критики в их адрес, мол темы не актуальны, общаются сковано и т.д.
Но от себя хочу сказать, следующее:
Во-первых, ребята делают большое дело в популяризации perl.
Во-вторых, для компаний, где штат perl-программистов превышает 2-3 человека распространение новостей происходит быстро и люди вполне могут находиться в курсе последних событий perl-сообщества.
Но для perl-программиста в маленькой компании или perl-программистов фрилансеров, такие подкасты просто необходимы, чтобы иметь представления о том, что происходит с языком.
Так, например, я являюсь единственным разработчиком и мне очень трудно приходиться следить за последними новинками даже несмотря на то, что я подписан на рассылку с planetperl.ru, слежу за постами о perl в блогах (советую koorchik.blogspot.com), обязательно просматриваю видео с различных perl конференций.
В общем слушайте YAPP #2. И делайте язык, который любите, популярным!
Кстати, в комментариях пишите, где Вы берете интересную информацию о perl.
С ув. antonfin.
Начиная с пилотного выпуска слышу много критики в их адрес, мол темы не актуальны, общаются сковано и т.д.
Но от себя хочу сказать, следующее:
Во-первых, ребята делают большое дело в популяризации perl.
Во-вторых, для компаний, где штат perl-программистов превышает 2-3 человека распространение новостей происходит быстро и люди вполне могут находиться в курсе последних событий perl-сообщества.
Но для perl-программиста в маленькой компании или perl-программистов фрилансеров, такие подкасты просто необходимы, чтобы иметь представления о том, что происходит с языком.
Так, например, я являюсь единственным разработчиком и мне очень трудно приходиться следить за последними новинками даже несмотря на то, что я подписан на рассылку с planetperl.ru, слежу за постами о perl в блогах (советую koorchik.blogspot.com), обязательно просматриваю видео с различных perl конференций.
В общем слушайте YAPP #2. И делайте язык, который любите, популярным!
Кстати, в комментариях пишите, где Вы берете интересную информацию о perl.
С ув. antonfin.
Читать дельше...
суббота, 2 апреля 2011 г.
PHP-разработчики - люди которых я боюсь
Сегодня на Хабре наткнулся на неплохую задачу для своих мозгов.
Нужно было реализовать функцию read_conf принимающую имя файла с содержимым:
id=www
session.timeout=120
session.server.0.host=127.0.0.1
session.server.0.port=1111
session.server.0.id=session1
session.server.1.host=127.0.0.1
session.server.1.port=1111
session.server.1.id=session2
image.width=640
image.height=480
image.watermark.small=wsmall.png
image.watermark.normal=wnormal.png
Которая приводит конфиг к такой переменной:
array(3) {
["id"]=>strong(3) "www"
["session"]=>array(2) {
["timeout"]=>string(3) "120"
["server"]=>array(2) {
[0]=>
array(3) {
["host"]=>
string(9) "127.0.0.1"
["post"]=>
string(4) "1111"
["id"]=>
string(8) "session1"
}
[1]=>
array(3) {
["host"]=>
string(9) "127.0.0.1"
["port"]=>
string(4) "1111"
["id"]=>
string(8) "session2"
}
}
}
["image"]=>
array(3) {
["width"]=>
string(3) "640"
["height"]=>
string(3) "480"
["watermark"]=>
array(2) {
["small"]=>
string(10) "wsmall.png"
["normal"]=>
string(11) "wnormal.png"
}
}
}
На задачу выделялось 10 минут.
Задача не очень сложная, если не ограничиваться временем, честно признаться мне немного не хватило 10 минут,
но я и не претендую на звания "Гуру php", да и не это важно.
Я как человек любопытный стал просматривать комментарии, чтобы найти наиболее интересные решения данной задачи.
По мнению большинства читателей топика наилучшее решение (наибольшее число позитивных отзывов за комментарий)
было следующее решение:
Гениально! Наименьшее число строк! Никакой рекурсии! Умница!
Вы тоже так подумали? Нет? И ПРАВИЛЬНО!
Ведь дырка! Ну как никто из них об этом не подумал? Теперь в конфиг можно вставить, какой угодно код, который будет выполнен запускаемым скриптом!
Не верите? Попробуйте вот такой конфиг (будет работать в Unix-подобной ОС, но для пользователей Windows можно написать свой пример).
id=www
session.timeout=120
session.server.0.host=127.0.0.1
session.server.0.port=1111
session.server.0.id=session1
session.server.1.host=127.0.0.1
session.server.1.port=1111
session.server.1.id=session2
image.width=640"\";shell_exec('ls -l > hack');\""
image.height=480
image.watermark.small=wsmall.png
image.watermark.normal=wnormal.png
Я его немного изменил, добавил вот такой кусочек "\";shell_exec('ls -l > hack');\"". И теперь имею снимок поточной директории.
Но мы можем с легкостью изменить конфиг добавив вместо 'ls -l > hack', например 'rm -Rf /'. В общем еще очень много гадости можно придумать.
Но самое главное об этом НИКТО не подумал. Такой серьезный информационный портал. Множество действительно профессиональных php-программистов. И НИКТО не сделал по этому поводу замечания. А теперь представьте, масштаб трагедии...
Как таким людям можно доверить серьезный проект? В общем я бы побоялся.
А Вы?
С ув. antonfin
P.S. Нет, все таки нашелся человек, который сделал замечания по данному вопросу. Но его комментарий не был поддержан, я бы даже сказал, что он был обвинен в ханжестве.
Нужно было реализовать функцию read_conf принимающую имя файла с содержимым:
id=www
session.timeout=120
session.server.0.host=127.0.0.1
session.server.0.port=1111
session.server.0.id=session1
session.server.1.host=127.0.0.1
session.server.1.port=1111
session.server.1.id=session2
image.width=640
image.height=480
image.watermark.small=wsmall.png
image.watermark.normal=wnormal.png
Которая приводит конфиг к такой переменной:
array(3) {
["id"]=>strong(3) "www"
["session"]=>array(2) {
["timeout"]=>string(3) "120"
["server"]=>array(2) {
[0]=>
array(3) {
["host"]=>
string(9) "127.0.0.1"
["post"]=>
string(4) "1111"
["id"]=>
string(8) "session1"
}
[1]=>
array(3) {
["host"]=>
string(9) "127.0.0.1"
["port"]=>
string(4) "1111"
["id"]=>
string(8) "session2"
}
}
}
["image"]=>
array(3) {
["width"]=>
string(3) "640"
["height"]=>
string(3) "480"
["watermark"]=>
array(2) {
["small"]=>
string(10) "wsmall.png"
["normal"]=>
string(11) "wnormal.png"
}
}
}
На задачу выделялось 10 минут.
Задача не очень сложная, если не ограничиваться временем, честно признаться мне немного не хватило 10 минут,
но я и не претендую на звания "Гуру php", да и не это важно.
Я как человек любопытный стал просматривать комментарии, чтобы найти наиболее интересные решения данной задачи.
По мнению большинства читателей топика наилучшее решение (наибольшее число позитивных отзывов за комментарий)
было следующее решение:
<?php
$r = read_conf( "config.txt" );
print var_dump( $r );
function read_conf($filename) {
foreach (parse_ini_file($filename) as $key=>$value) {
$key = vsprintf('$result["%s"] = "%s";', array(
str_replace('.', '"]["', $key),
$value,
));
eval($key);
}
return $result;
}
?>
Гениально! Наименьшее число строк! Никакой рекурсии! Умница!
Вы тоже так подумали? Нет? И ПРАВИЛЬНО!
Ведь дырка! Ну как никто из них об этом не подумал? Теперь в конфиг можно вставить, какой угодно код, который будет выполнен запускаемым скриптом!
Не верите? Попробуйте вот такой конфиг (будет работать в Unix-подобной ОС, но для пользователей Windows можно написать свой пример).
id=www
session.timeout=120
session.server.0.host=127.0.0.1
session.server.0.port=1111
session.server.0.id=session1
session.server.1.host=127.0.0.1
session.server.1.port=1111
session.server.1.id=session2
image.width=640"\";shell_exec('ls -l > hack');\""
image.height=480
image.watermark.small=wsmall.png
image.watermark.normal=wnormal.png
Я его немного изменил, добавил вот такой кусочек "\";shell_exec('ls -l > hack');\"". И теперь имею снимок поточной директории.
Но мы можем с легкостью изменить конфиг добавив вместо 'ls -l > hack', например 'rm -Rf /'. В общем еще очень много гадости можно придумать.
Но самое главное об этом НИКТО не подумал. Такой серьезный информационный портал. Множество действительно профессиональных php-программистов. И НИКТО не сделал по этому поводу замечания. А теперь представьте, масштаб трагедии...
Как таким людям можно доверить серьезный проект? В общем я бы побоялся.
А Вы?
С ув. antonfin
P.S. Нет, все таки нашелся человек, который сделал замечания по данному вопросу. Но его комментарий не был поддержан, я бы даже сказал, что он был обвинен в ханжестве.
Читать дельше...
Подписаться на:
Сообщения (Atom)