• 3 задачи, которые отсеивают 9 из 10 «Senior PHP» кандидатов
    0
    >юлозит вульвой
    крутое выражение, надо запомнить
  • 3 задачи, которые отсеивают 9 из 10 «Senior PHP» кандидатов
    0
    У нас тест является обязательным при наборе, идет вдобавку к резюме.

    Беглый взгляд на тест (5 задачи, пхп, базы, ксс+js, архитектурная) позволяет отсеять 90% людей, которые не подходят.

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

    Дайте 3-5 задач типа тычки-галочки + две такие свободные, где надо порассуждать, и не принимайте на собеседование без них.

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

  • О неверности обобщений, или каждый программист — уникален
    0
    в одном комменте видел

    а может, просто за общий посыл статьи.
  • О неверности обобщений, или каждый программист — уникален
    +5
    Надо радоваться.
    Ура, я женщина! (С)
  • О неверности обобщений, или каждый программист — уникален
    0
    его, похоже, за мат забанили.

    добавил строку в начало поста.
    если три коммента еще будет — уберу в черновики.
  • О неверности обобщений, или каждый программист — уникален
    0
    Я вот тоже думаю.
    Убрать в черновики может?
  • О неверности обобщений, или каждый программист — уникален
    0
    >Масло маслянное? В ошибках программирования, наверное тоже, виноват только программист.
    Ну модно (и я был таким раньше, и иногда бываю сейчас) обвинять кого угодно, только не себя. Не те программисты — вот посыл статьи.

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

    Ну и я высказал свое мнение на этот счет, насчет идеального. Цитирую: «Идеальный программист не пишет плохой код, не срывает сроков и не существует.»

    >Так что — да, каждый программист уникален. Что, однако, не мешает вам выбирать из программистов тех, кто лучше всего справится с Вашими задачами, и не уйдёт раньше срока.

    Согласен
  • О неверности обобщений, или каждый программист — уникален
    +2
    офигеть, его самого забанили? странно.
    жалко вообще.

    он же вроде не матерился, просто написал свой взгляд
  • О неверности обобщений, или каждый программист — уникален
    +12
    Он достаточно крутой человек вообще, посмотрел пару постов. Поднял бизнес, как понимаю, с нуля, создал рабочие места. Молодец :)

    Просто в эмоциях написал статью, с которой я не совсем согласен. Никто же не запрещает обмен мнениями?
  • О неверности обобщений, или каждый программист — уникален
    +9
    спасибо за замечание.
    откорректировал, добавил, что это только мое мнение, плюс смягчил формулировку.

    это сугубо мой опыт анализа ухода нескольких десятков программистов, и необязательно верный. но удивительным образом работающий даже в несхожих с моей управленческой практикой ситуациях. вообще, брать на себя ответственность и думать, как избежать чего-то негативного в будущем, даже если это было случайностью — хороший момент для собственного развития.
  • Функциональное программирование на PHP
    –1
    Знаете в чем прикол?

    Напишите эту логику на стороне БД, и работать иногда будет раз в 10-100 быстрее. :)
    Иногда скорость важнее красоты
  • Valve предлагает пользователям Windows попробовать Steam для Linux
    +32
    Initializing Motivation Protocol…
  • Насколько плохим код должен быть?
    0
    ну если мы обработку, какие баннеры, перенесем на клиента, будет ппц)
  • Насколько плохим код должен быть?
    0
    ну там уже до нас было кеширование в виде файлов. изначально структура была слишком крутая и универсальная, и все варианты показа баннеров обсчитывались в ПХП ООП :) мы упростили структуру еще к тому же, провели рефакторинг.
  • Насколько плохим код должен быть?
    +1
    Могу сказать про недавний опыт.

    Мы переписывали движок баннерокрутилки, полученный от коллег. Наш хороший разработчик переписал все на ООП PHP. Мы пытались что-то оптимизировать, но оно даже под абешкой не взлетало (50 запросов в секунду должно плевать с одного сервака, получали 99% fails).
    В конце-концов в результате оптимизаций на профайлинге стала очевидность важности правильной архитектуры. Ниже этапы оптимизации и вывод.
    1. Сначала убрали лишнее ООП. Помогло, не сильно
    2. Увидели, что крутые ООП-оболочки над БД сильно тормозят. Переписали на голом PDO
    3. Но и голое PDO стало тормозить. 90% времени съедает, 400 мс.
    4. По моему предложению перенесли логику в БД. Так как там была операция в цикле и ряд запросов.
    5. Сначала хранимки в БД написали " в лоб" — циклы и тд. Помогло, не сильно — 50% не работало под нагрузкой.
    6. С участием нашего DBA, выдающего специалиста, переделали циклы в хранимке на язык реляционной БД — в один запрос, убрали временные таблицы из логики, и так далее.
    7. В итоге менее 10% фейлов, и система стала жить на нагрузке.

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

    А вовсе не тупые оптимизации, вроде давайте заменим двойные кавычки на одинарные, или там заменим кусок сишного кода на ассемблер. А умные, которые неразрывно связаны с проникновением в предметную область задачи и понимания условий, в которых приложение будет работать.
  • R’ha — короткометражный анимационный фильм немецкого студента, открывший ему двери в Голливуд
    +3
    Для того, чтобы люди ассоциировали какие-то НЕХ с реальностью, часто нужно их наделять эмоциональными поступками, и нередко — антропологичностью.

    Почитайте у Каганова на эту тему. Супер-повесть про кротовые норы отсасывает, а повесть про живую машину вдруг становится популярной. Хотя в первой ДОСТОВЕРНОСТИ может быть миллион. А способности ВЫЗЫВАТЬ ЭМОЦИИ у зрителя/читателя — минимум.

    Поэтому парень все сделал верно.
  • В MIT разработали синтетическую «мышцу», работающую на воде
    0
    Крайне интересно.

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

    Значит, давайте по-порядку.

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

    Во-вторых, аяксовое сохранение по CTRL+Enter мне было не сразу понятно. Оно скидывает в черновики, хотя логичнее было бы публиковать (именно эта кнопка основная).

    В-третьих, где запрещение этого правилами?

    В-четвертых, я стараюсь писать содержательные статьи, и о разном. Сам не люблю воду.
  • Перекресток семи дорог, или о выборе пути для программиста
    0
    (дубль)
  • Перекресток семи дорог, или о выборе пути для программиста
    +1
    Десяток, сайты визитки, средненькие и интернет магазины. Надоеоло потому, что это конвеер и рутина. Щас уже знаю, что либо нало было стандартизировать, автоматизировать и продавать в десять раз больше, либо паспозиционироваться и добиться успешых продаж за цену в десять раз больше. А тогда мыслил только как программист и интепеса не видел
  • Перекресток семи дорог, или о выборе пути для программиста
    +1
    что нравится в ваших комментах, так это мудрый и взвешенный взгляд на жизнь
  • Перекресток семи дорог, или о выборе пути для программиста
    0
    Ну мы делаем IT в туризме. К примеру, наш проект это Tophotels.ru
    Много крутых проектов, лидируем на рынке.

    я занимаюсь внутренней автоматизацией, расти еще очень много
  • Перекресток семи дорог, или о выборе пути для программиста
    –4
    я не сразу осилил пересохранение
  • Перекресток семи дорог, или о выборе пути для программиста
    0
    мы делали типовой движок — всякие справочники, карты, блог, новостная система, фотообзоры живые, видео и тд.

    чтобы потом его на другие города масштабировать (был успешный пример из другого региона).

    в общем, там было непросто :)
  • Перекресток семи дорог, или о выборе пути для программиста
    –1
    я, кстати, не так часто пишу статьи.
    стараюсь в тему и чтобы они были достаточно полезны.

    данная есть изложение моего опыта
  • Перекресток семи дорог, или о выборе пути для программиста
    –1
    +100
  • Перекресток семи дорог, или о выборе пути для программиста
    +3
    в основном, у меня стартапы не взлетали по другим причинам
    — неверный рынок. сильная конкуренция, высокий порог входа
    — неверная модель монетизации, думали о продукте, а не о том, как заработать денег
    — слабая управленческая сторона вопроса

    но некоторые взлетели. самое простое и незатейливое взлетело :)
  • Пять причин быть управленцем
    0
    Согласен, что не только для управленца. Для профессионалов во многих сферах подходят.

  • Пять причин быть управленцем
    +1
    я то же самое написал

    мысли схожи))

    Отмечу, что мне нравится ООП в Джаве, она в этом плане реально рулит. Ну и стек готовых технологий, фреймворков очень достоин, ничуть не хуже плюсов по полноте)
  • Пять причин быть управленцем
    +1
    IMHO разумеется.

    Кого-то тошит от плюсов и он боготворит Джаву, или си шарп.

    А так, любой язык под свои задачи. Офисную автоматизацию я писал на Дельфях, клиент-серверное приложение для управление роботом Кавасаки на с++, под веб — в зависимости от задач, ASP/.NET, потом был перл, питон, пхп.
    Все это можно и на Джаве, и на сях написать с определенными усилиями, но зачем?
  • Пять причин быть управленцем
    0
    и Java, и .NET обладает рядом существенных недостатков (и технических, и организационных, связанных с разработкой на этих платформах и разработчиками).

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

    впрочем, в современном мире железом можно заткнуть даже тормозную и глюкавую платформу. и это дело вкуса, как говорится.
  • Пять причин быть управленцем
    0
    Single point of truth = SPOT = DRY

    KISS = keep it simple, stupid

    эвристические правила, работают много где
  • Suit Up! Простой и легкий WYSIWYG
    0
    Супер!
    Молодец, уважаю таких, кто создает.
  • 13 причин не быть управленцем
    0
    если не секрет, когда вы за отметку топа вышли ($120k/year)?

  • 13 причин не быть управленцем
    0
    да, я читал
    очень крутой Уэлч.
  • Пять причин быть управленцем
    0
  • Пять причин быть управленцем
    0
    >например, если проектировщик такой умный в юмл-диаграммах, то почему надо кому-то повторять работу? Пусть генерирует код из них. Или сам и пишет

    +1000
  • Пять причин быть управленцем
    +1
    Я у себя выбросил ежедневные митинги, совещания и тд.
    только при необходимости.

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

    если бы все еще это юзали, но это другой вопрос:)
  • Пять причин быть управленцем
    0
    искусство войны?
  • Пять причин быть управленцем
    0
    >Недавно показательная вещь случилась. Говорю: полдня надо еще, чтобы полностью покрыть тестами. Человек, который уж очень хочет забрать код, говорит: «не надо, мы тебе и так доверяем». В итоге нашли баг, который был как раз в том месте, не покрытом тестами. Но они потратили 2 дня на его поиски. (не ТДД, каюсь, но то был проект — взять готовый код, оптимизировать и рефакторить).

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

    коммуникации рулят.

    >Потому что рефакторинг — часть процесса, он должен быть незаметным и проводиться всё время. А если тормознули на полгода, значит говнокодили до этого долго и дошли до точки.

    золотые слова!