Надо выделить из своего опыта, о чем было бы круто рассказать. Всего месяц остался.
На декабрьской конференции самый эпичный для меня доклад был про сверление айфонов в Яндексе. Именно «эпичный» — не думаю, что много практической пользы вынес, но вышел оттуда воодушевлённым, хотелось что-нибудь немедленно спаять.
Не понял, как тут может быть в принципе идеализация руководства, если(хотя бы формально) статья предназначена именно для руководителей, которые хотят стать лучше?
Ну как это зачем?
Очевидно, что прибывает посылок за единицу времени больше, чем может обработать за ту же единицу московская таможня.
Если все их через неё пропускать, то либо сроки ожидания будут расти до бесконечности, как с гринкард для родственников в США случилось, либо какие-то посылки не будут доставлены никогда.
>Почему бы не начать изменения с СЕБЯ?
Например, потому что изменять себя в худшую сторону не хочется?
Лояльность компании — хорошая вещь(в первую очередь, впрочем, для компании).
Но от разговоров в ключе «сколько компания на твоем труде заработает» она может только уменьшиться.
>Проблем на почте всегда хватало (а основные проблемы ведь не в ней, а в таможне), но почему-то только в последнее время идёт массовый психоз по этому делу. Раньше были «нечестные выборы», теперь вот почта.
То есть вы хотите сказать, что выборы были всегда нечестные, и так тут заведено, чего рыпаться?
Принимал участие в разработке системы трекинга, которая сейчас используется в DHL. Там никаких особенно фантастических технологий нет, разве что не нужно вручную сканировать штрих-код, как на Почте России, а просто RFID-метка срабатывает, когда коробка проезжает через рамку. Трекинг по Cell ID и GPS есть, но для посылок, отправляемых физлицами, он не применяется.
>Для меня ваша фраза означает, что хоть программист и делает кучу дефектов и тут и там, его работа по-прежнему может считаться качественной.
Я так понимаю, вы считаете это абсурдным? Почему?
Критерием качества продукта(причем, если над проектом работает команда, то качество продукта напрямую так просто не транслировать в качество работы каждого конкретного её члена) является наличие дефектов в финальном билде. В промежуточном их может быть сколько угодно, с качеством финального продукта это никак не коррелирует. Вопрос с метриками качества работы программиста сложный, мне неизвестен «правильный» ответ на него, но хорошо известно, что измерять его дефектами такая же ерунда, как и измерять строками написанного кода производительность.
Это настолько общее место, что я теряюсь, какие тут можно дать ссылки. Вторая глава классической книги Канера, Фолка и Нгуена? Она скорее о невозможности полного тестирования. И Art of Software Testing из далекого 1979 года туда же. Цитата Дийкстры «If debugging is the process of removing bugs, then programming must be the process of putting them in?» Так это про дебаггинг. Вот тут, например, этот вопрос обсуждали — так закрыли тему за неконструктивность: programmers.stackexchange.com/questions/41248/how-to-be-a-zero-bug-programmer Здесь рядом тоже люди об этом говорят: habrahabr.ru/post/149240/
В общем, много можно копать. Доказывать общие места дело неблагодарное А вот какая методология советует измерять качество работы числом багов? Такие есть? Они эффективны?
Можно также привести примеры и придумать аналогии для иллюстрации. Программист написал код строго по спецификации, но с железом (его делала 3rd party) код работает неправильно — в спецификации не указано, Little Endian или Big Endian должен быть использован и используются разные. Программист виноват? Программа с целью экономии памяти/реюза компонентов/ещё чего-то позволяет имена файлов не более 11 символов. Программист непрофессионален из-за того, что не реализовал современную фичу? А из-за того, что забыл посчитать точку в MS-DOS формате? Отвечает ли писатель за то, правильно ли расставлены переносы в его книге? А за орфографические ошибки? Ну, вы знаете, хорошие писатели — они же, по идее, весьма образованные люди, должны писать без ошибок?
>Вся их работа упирается в то, что изначальная работа разработчиков сделана некачественно.
Вот это очень важная для всего следующего ниже посылка, но она в корне неверная. Качество работы программиста не определяется наличием или отсутствием в его коде дефектов. Более слабый программист чаще будет делать глупые ошибки в простых вещах, но расширять эту корреляцию дальше нельзя. Это было сказано, кажется, ещё до того, как вообще придумали отдельного человека — тестировщика ПО, и что-то я не слышал, чтобы это опровергли. Вы же сами говорите, что в действительности того гипотетического диалога с заказчиком не бывает.
Да, к слову, я в курсе, что Литрес не очень хорошие ребята и сами вроде как чужие тексты не прочь продать за деньги, последний абзац не про них, а так, гипотетический.
А чем его работа со сносками особенно хороша?
Footnotes в кулридере работают замечательно. Причем именно они были моим самым главным восторгом(помимо сглаженных шрифтов) при переходе с win mobile/alreader на android/coolreader — там их у меня не было, то ли версия старая, то ли 320*240 не способствовало, то ли и то, и другое. А так вообще отличная была программа, разве что скин по умолчанию с этими часами во весь экран — НУ ЗАЧЕМ! У себя, допустим, убрал сразу, но в метро ещё десятки пользователей, и они все читают с текстом поверх часов, аааа!
Не могу с вами согласиться.
Продавать цифровую копию Пушкина можно.
В конце концов, электронная книга тоже требует ресурсов для создания: например, текст из печатного исходника нужно распознать и сверстать. Плюс библиотеку надо хостить где-то, если это библиотека. Мы же не требуем бесплатной раздачи печатных книг, вроде бы? А отличие тут только в простоте создания копий, но никак не исходной книги, даже если текст её public domain.
Нехорошо при этом мешать другим раздавать Пушкина бесплатно(раз уж они это могут себе позволить). Это некрасивая конкуренция.
Сложный вопрос, как хорошо правильно поступать, если ты потратил ресурсы на создание электронной библиотеки, а кто-то взял твои файлы и продает их или раздает условно-бесплатно, получая при этом деньги от рекламы и пожертвований, я затрагивать сейчас не хочу.
Быть-то они были, а массовыми — едва ли. По поп-культуре это хорошо видно. Ни в Miami Vice, ни в Twin Peaks(80е, начало 90х) — никаких мобильных телефонов нет вообще; а в X-Files или Friends(90е) в первых сезонах нет, а потом постепенно появляются.
Это в общем к чему я клоню. Что, видимо, срок в 30 лет для многих серьёзных, больших штук оказывается слишком коротким и отсекает открытия и изобретения от их всеобщего проникновения. В 2005 году, скажем, я работал в компании, разрабатывавшей мобильный браузер и вместе со многими коллегами недоумевал, кому вообще нужна такая фигня, а через пять лет все уже со смартфонов в интернете фигачили. А с чем-то покрупнее пяти лет недостаточно, сейчас кажется, что это ерунда, а оно через 15 лет изменит мир.
Сотовая связь радикально преобразила жизнь человечества, а в этом списке упомянута только в виде «айфона».
Хотя если буквоедствовать, то её можно тоже вместе с интернетом в 70е впихнуть. Но реально это не так ведь, и интернет, и мобильные телефоны стали массовыми только в 90х.
Вы передергиваете.
Много ли есть операционных систем без текстового редактора, чтобы это «изобретение» было действительно полезно?
Или это удобнее, чем нажать (в виндоус) Win+R, notepad?
Документы гугла обладают функциональностью, которая, во-первых, не входит в стандартные комплекты поставки операционных систем(хотя можно реализовать, скажем, связкой дропбокса и офиса), во-вторых, достаточно сложна в реализации(офис и дропбокс нужны на каждом ПК, планшете и телефоне).
Это же действительно не более чем курьёз.
На декабрьской конференции самый эпичный для меня доклад был про сверление айфонов в Яндексе. Именно «эпичный» — не думаю, что много практической пользы вынес, но вышел оттуда воодушевлённым, хотелось что-нибудь немедленно спаять.
Очевидно, что прибывает посылок за единицу времени больше, чем может обработать за ту же единицу московская таможня.
Если все их через неё пропускать, то либо сроки ожидания будут расти до бесконечности, как с гринкард для родственников в США случилось, либо какие-то посылки не будут доставлены никогда.
Например, потому что изменять себя в худшую сторону не хочется?
Лояльность компании — хорошая вещь(в первую очередь, впрочем, для компании).
Но от разговоров в ключе «сколько компания на твоем труде заработает» она может только уменьшиться.
То есть вы хотите сказать, что выборы были всегда нечестные, и так тут заведено, чего рыпаться?
Я был в командировке 53 дня, в первый же день отправил жене домой открытку — сам вернулся раньше.
Я так понимаю, вы считаете это абсурдным? Почему?
Критерием качества продукта(причем, если над проектом работает команда, то качество продукта напрямую так просто не транслировать в качество работы каждого конкретного её члена) является наличие дефектов в финальном билде. В промежуточном их может быть сколько угодно, с качеством финального продукта это никак не коррелирует. Вопрос с метриками качества работы программиста сложный, мне неизвестен «правильный» ответ на него, но хорошо известно, что измерять его дефектами такая же ерунда, как и измерять строками написанного кода производительность.
Это настолько общее место, что я теряюсь, какие тут можно дать ссылки. Вторая глава классической книги Канера, Фолка и Нгуена? Она скорее о невозможности полного тестирования. И Art of Software Testing из далекого 1979 года туда же. Цитата Дийкстры «If debugging is the process of removing bugs, then programming must be the process of putting them in?» Так это про дебаггинг. Вот тут, например, этот вопрос обсуждали — так закрыли тему за неконструктивность: programmers.stackexchange.com/questions/41248/how-to-be-a-zero-bug-programmer Здесь рядом тоже люди об этом говорят: habrahabr.ru/post/149240/
В общем, много можно копать. Доказывать общие места дело неблагодарное А вот какая методология советует измерять качество работы числом багов? Такие есть? Они эффективны?
Можно также привести примеры и придумать аналогии для иллюстрации. Программист написал код строго по спецификации, но с железом (его делала 3rd party) код работает неправильно — в спецификации не указано, Little Endian или Big Endian должен быть использован и используются разные. Программист виноват? Программа с целью экономии памяти/реюза компонентов/ещё чего-то позволяет имена файлов не более 11 символов. Программист непрофессионален из-за того, что не реализовал современную фичу? А из-за того, что забыл посчитать точку в MS-DOS формате? Отвечает ли писатель за то, правильно ли расставлены переносы в его книге? А за орфографические ошибки? Ну, вы знаете, хорошие писатели — они же, по идее, весьма образованные люди, должны писать без ошибок?
Вот это очень важная для всего следующего ниже посылка, но она в корне неверная. Качество работы программиста не определяется наличием или отсутствием в его коде дефектов. Более слабый программист чаще будет делать глупые ошибки в простых вещах, но расширять эту корреляцию дальше нельзя. Это было сказано, кажется, ещё до того, как вообще придумали отдельного человека — тестировщика ПО, и что-то я не слышал, чтобы это опровергли. Вы же сами говорите, что в действительности того гипотетического диалога с заказчиком не бывает.
а вообще, в википедии очень подробный сборник таблиц есть:
en.wikipedia.org/wiki/List_of_displays_by_pixel_density
Footnotes в кулридере работают замечательно. Причем именно они были моим самым главным восторгом(помимо сглаженных шрифтов) при переходе с win mobile/alreader на android/coolreader — там их у меня не было, то ли версия старая, то ли 320*240 не способствовало, то ли и то, и другое. А так вообще отличная была программа, разве что скин по умолчанию с этими часами во весь экран — НУ ЗАЧЕМ! У себя, допустим, убрал сразу, но в метро ещё десятки пользователей, и они все читают с текстом поверх часов, аааа!
Продавать цифровую копию Пушкина можно.
В конце концов, электронная книга тоже требует ресурсов для создания: например, текст из печатного исходника нужно распознать и сверстать. Плюс библиотеку надо хостить где-то, если это библиотека. Мы же не требуем бесплатной раздачи печатных книг, вроде бы? А отличие тут только в простоте создания копий, но никак не исходной книги, даже если текст её public domain.
Нехорошо при этом мешать другим раздавать Пушкина бесплатно(раз уж они это могут себе позволить). Это некрасивая конкуренция.
Сложный вопрос, как хорошо правильно поступать, если ты потратил ресурсы на создание электронной библиотеки, а кто-то взял твои файлы и продает их или раздает условно-бесплатно, получая при этом деньги от рекламы и пожертвований, я затрагивать сейчас не хочу.
Это в общем к чему я клоню. Что, видимо, срок в 30 лет для многих серьёзных, больших штук оказывается слишком коротким и отсекает открытия и изобретения от их всеобщего проникновения. В 2005 году, скажем, я работал в компании, разрабатывавшей мобильный браузер и вместе со многими коллегами недоумевал, кому вообще нужна такая фигня, а через пять лет все уже со смартфонов в интернете фигачили. А с чем-то покрупнее пяти лет недостаточно, сейчас кажется, что это ерунда, а оно через 15 лет изменит мир.
АААА
Хотя если буквоедствовать, то её можно тоже вместе с интернетом в 70е впихнуть. Но реально это не так ведь, и интернет, и мобильные телефоны стали массовыми только в 90х.
Много ли есть операционных систем без текстового редактора, чтобы это «изобретение» было действительно полезно?
Или это удобнее, чем нажать (в виндоус) Win+R, notepad?
Документы гугла обладают функциональностью, которая, во-первых, не входит в стандартные комплекты поставки операционных систем(хотя можно реализовать, скажем, связкой дропбокса и офиса), во-вторых, достаточно сложна в реализации(офис и дропбокс нужны на каждом ПК, планшете и телефоне).
Это же действительно не более чем курьёз.