Главное — это уметь в любой момент собрать волю в кулак и заставить себя делать то, что порой не хочется, но нужно. В этом весь секрет.
Да, это прекрасный совет, если есть ОДНО дело, которое нужно делать. Кстати, именно поэтому появляются заявления типа «если вы будете полностью загружены работой, никакой тайм-менеджмент не нужен».
Однако как только дел становится несколько, всё становится совсем не просто. Какое из дел нужно заставить себя делать? И как быть с остальными делами? И как быть с той самой горой мелочи, которая остаётся несделанной, отравляет жизнь и порождает всё более и более серьёзные проблемы?
Тайм-менеджмент необходим, но надо помнить, что:
— Тайм-менеджмент — не цель, а средство. Если на тайм-менеджмент начинает уходить чуть ли не половина времени, то смысл его теряется.
— Нет универсальной системы. Мы все люди, у каждого своя ситуация, свои особенности психики, свой образ жизни. Каждую систему нужно подстраивать и перекраивать под себя.
— Система действует тогда, когда она становится частью жизни. За несколько недель этого не произойдёт. Бессмысленно прыгать с одноцй системы на другую — стоит пытаться освоить одну, модифицировать ее, и только когда становится совершенно ясно, что она не годится, обдумывать переход на другую.
В теории это, конечно, проблема. Но на практике это означает, что:
а) были атакованы сайты, хранящие пароли в открытом виде;
б) пароли с разных сайтов попали в руки одних и тех же злоумышленников;
в) они аггрегировали пароли по имени пользователя;
г) они либо специально рассматривали один аккаунт и изучали пароли к нему, либо прогнали какой-то хитрый скрипт, который выискивает закономерности.
Как мне кажется, это на сегодняшний день маловероятный сценарий.
Проще всего придумать правило для генерации пароля с использованием, скажем, имени сайта. Ну, например, строить пароль так:
Ya+hochu+zajti+na+[имя сайта]
То есть для Хабра будет Ya+hochu+zajti+na+habrahabr
Для Гугла Ya+hochu+zajti+na+google
Весьма стойко — пароли получаются длинные, подбором их взять нереально. Запоминается очень легко, не надо записывать. На разных сайтах — разные пароли.
Я вовсе не считаю, что примитивная графика несовершенна. Графика является некоей абстракцией представления окружающего мира (не знаю, можно ли так сказать :) ). В начале игры задаётся уровень этой абстракции, и дальше мозг игрока подстраивается под него. Главное, чтобы этот уровень был постоянным и чтобы он соответствовал сути игры.
Я бы сказал «из-за неадекватной сложности». Например, в авиасимуляторах управление не просто сложное — оно запредельно сложное. Но именно это, как мне кажется, и привлекает любителей этого жанра, поскольку эта сложность адекватно симулирует сложность управления настоящим самолётом.
Общая идея такова: сложность управления должна быть адекватна сложности действия в игровом мире. Если в игре для того, чтобы отдать простую команду подчинённым, нужно нажать 8 кнопок (к примеру), а в игре это соответствует тому, что персонаж произносит в рацию «группа Альфа — вперёд!», то это нехорошо.
Ну, оно всё, конечно, верно… Но с одной стороны приводимые правила очень общи и обтекаемы, а с другой стороны из каждого правила очень много исключений. Ну, вот например:
«Выбор кнопок и их функции должны быть обусловлены исключительно удобством пользователя.» В некоторых случаях, наоборот, выбор кнопок может быть обусловлен предполагаемой сложностью действия в игре. Пример — «комбо» в драках. Вряд ли можно сказать, что удобноб если для тройного удара ногой в прыжке нужно за доли секунды нажать кнопки A,A,X,A,B. Но сложность в освоении этой комбинации симулирует сложность боевого приёма, и в преодолении этого неудобства и состоит часть игры.
Есть очень много примеров того, что качество графики не однозначно соответствует качеству игры. Например, Minecract и Braid — примеры очень успешных и увлекательных игр с весьма примитивной графикой. Ну, а про горы дурных игрушек, в которых графика вполне на уровне и говорить нечего :)
Не важно, как красив Ваш код, если он не работает.
Как раз наоборот: красивый и аккуратный код гораздо легче чинить.
Рефакторинг только тогда, когда он необходим, а не когда Вам не нравится код. Отсутствие симпатии к чему-либо НЕ ЯВЛЯЕТСЯ причиной достаточной, чтобы изменять это.
У программиста со временем вырабатывается чутьё. Я точно знаю, что если мне не симпатичен код, в подавляющем большинстве случаев он несёт в себе скрытые проблемы.
Юнит тесты очень ограничены, когда дело доходит до интеграции. Проводите реальное, ручное тестирование!!!
Юнит тесты НЕ ПРЕДНАЗНАЧЕНЫ для интеграции. Тестирование интергции — это отдельная тема, где есть место и ручному, и сильно автоматизированному тестированию.
Дело даже не в сообразно-несообразно, бывает так, что в самом начале и проектировать-то, вроде, нечего — запрашивается тривиальная маленькая временная утилитка. А потом вдруг оказывается, что она каким-то образом превратилась в важнейший инструмент…
У меня был такой случай. Меня попросили написать ма-а-аленький инструментик, буквально страничку для ввода данных с тремя-четырьмя полями, и скриптик, который эти поля определённым образом запишет в файлик. При этом объяснили, что пользоваться скриптом будет один, ну максимум два человека, и что вообще всё это временно, пока этот функционал не будет включён в другой инструмент.
Потом попросили добавить ещё два маленьких поля… потом появилась маленькая развилочка в логике… Притом всё это всегда происходило в режиме «быстренько-быстренько, не отвлекайся от своего основного проекта, это всё временно». Мда…
В общем, через примерно год я вдруг обнаружил, что:
— Инструментом пользуются — и очень активно — человек 10.
— Они, оказываются. воспринимают эту временную залепуху как один из основных инструментов.
— Никто и не думает включать эту функциональность ни в какой другой инструмент;
— Временный код разбух и превратился в чёрт знает что, а времени на переписывание и приведение в приличный вид никто давать не хочет.
Я, конечно, сам виноват — не уследил. Но и до сих пор я не понимаю до конца — в какой именно момент надо было остановиться, упереться рогом и всё переделать? И как было в необходимости этого убедить начальство?..
Изобретение велосипедов — позитив в личном, так сказать, творчестве. Замечательно, когда специалист придумывает свой фреймворк, библиотеку, язык программирования…
Но плохо, когда он этим начинает заниматься в рамках постороннего проекта без необходимости. Ещё раз подчеркну: без необходимости. Разработка толкового фреймворка — довольно дорогое удовольствие, да и не каждый на это способен.
Да, я вполне понимаю Ваши аргументы. Плохо, когда нет понимания, что происходит на самом деле.
Но, с другой стороны, фреймворк — это просто инструмент, определённый уровень абстракции. Языки программирования это ведь тоже абстракция, верно? Объектная модель в С# — это на самом деле абстракция над CLR кодом. Требуете ли Вы от соискателя заодно и понимания того, как именно работает CLR?
Я не знаю, в других областях, возможно, и по-другому, но, скажем, я не представляю себе написание мало-мальски серьёзного серверного приложения на Яве без использования фреймворков. Да и не очень понятно, зачем…
Кстати, технологии указываются не только «для балласта». По ним виден кругозор, зачастую профессиональная биография, интересы. Ну и кроме того, некоторые из них могут быть полезны, даже если их знают не очень уверенно.
Главная задача сопроводительного письма — за 5-10 секунд убедить читающего, что ему имеет смысл потратить чуть больше времени и прочитать прилагающееся резюме :)
Насчёт «косяка» не знаю; но сам участвовал в проекте, у которого были огромные трудности по схожей причине. Несколько программистов — хороших программистов! — до проекта писали на C++. Проект был на Яве. Программисты разницу понимали, но не чувствовали.
Это смотря откуда. При попытке вынести, например, из серьёзного банка (кстати — там почти у всех пользователей отключена возможность использовать флешки) могут быть весьма неприятные последствия, типа ареста и срока.
Про загрузку из банка исходников куда-нибудь не другой сайт лучше и не говорить.
Да, это прекрасный совет, если есть ОДНО дело, которое нужно делать. Кстати, именно поэтому появляются заявления типа «если вы будете полностью загружены работой, никакой тайм-менеджмент не нужен».
Однако как только дел становится несколько, всё становится совсем не просто. Какое из дел нужно заставить себя делать? И как быть с остальными делами? И как быть с той самой горой мелочи, которая остаётся несделанной, отравляет жизнь и порождает всё более и более серьёзные проблемы?
Тайм-менеджмент необходим, но надо помнить, что:
— Тайм-менеджмент — не цель, а средство. Если на тайм-менеджмент начинает уходить чуть ли не половина времени, то смысл его теряется.
— Нет универсальной системы. Мы все люди, у каждого своя ситуация, свои особенности психики, свой образ жизни. Каждую систему нужно подстраивать и перекраивать под себя.
— Система действует тогда, когда она становится частью жизни. За несколько недель этого не произойдёт. Бессмысленно прыгать с одноцй системы на другую — стоит пытаться освоить одну, модифицировать ее, и только когда становится совершенно ясно, что она не годится, обдумывать переход на другую.
а) были атакованы сайты, хранящие пароли в открытом виде;
б) пароли с разных сайтов попали в руки одних и тех же злоумышленников;
в) они аггрегировали пароли по имени пользователя;
г) они либо специально рассматривали один аккаунт и изучали пароли к нему, либо прогнали какой-то хитрый скрипт, который выискивает закономерности.
Как мне кажется, это на сегодняшний день маловероятный сценарий.
Ya+hochu+zajti+na+[имя сайта]
То есть для Хабра будет Ya+hochu+zajti+na+habrahabr
Для Гугла Ya+hochu+zajti+na+google
Весьма стойко — пароли получаются длинные, подбором их взять нереально. Запоминается очень легко, не надо записывать. На разных сайтах — разные пароли.
Общая идея такова: сложность управления должна быть адекватна сложности действия в игровом мире. Если в игре для того, чтобы отдать простую команду подчинённым, нужно нажать 8 кнопок (к примеру), а в игре это соответствует тому, что персонаж произносит в рацию «группа Альфа — вперёд!», то это нехорошо.
«Выбор кнопок и их функции должны быть обусловлены исключительно удобством пользователя.» В некоторых случаях, наоборот, выбор кнопок может быть обусловлен предполагаемой сложностью действия в игре. Пример — «комбо» в драках. Вряд ли можно сказать, что удобноб если для тройного удара ногой в прыжке нужно за доли секунды нажать кнопки A,A,X,A,B. Но сложность в освоении этой комбинации симулирует сложность боевого приёма, и в преодолении этого неудобства и состоит часть игры.
Не важно, как красив Ваш код, если он не работает.
Как раз наоборот: красивый и аккуратный код гораздо легче чинить.
Рефакторинг только тогда, когда он необходим, а не когда Вам не нравится код. Отсутствие симпатии к чему-либо НЕ ЯВЛЯЕТСЯ причиной достаточной, чтобы изменять это.
У программиста со временем вырабатывается чутьё. Я точно знаю, что если мне не симпатичен код, в подавляющем большинстве случаев он несёт в себе скрытые проблемы.
Юнит тесты очень ограничены, когда дело доходит до интеграции. Проводите реальное, ручное тестирование!!!
Юнит тесты НЕ ПРЕДНАЗНАЧЕНЫ для интеграции. Тестирование интергции — это отдельная тема, где есть место и ручному, и сильно автоматизированному тестированию.
У меня был такой случай. Меня попросили написать ма-а-аленький инструментик, буквально страничку для ввода данных с тремя-четырьмя полями, и скриптик, который эти поля определённым образом запишет в файлик. При этом объяснили, что пользоваться скриптом будет один, ну максимум два человека, и что вообще всё это временно, пока этот функционал не будет включён в другой инструмент.
Потом попросили добавить ещё два маленьких поля… потом появилась маленькая развилочка в логике… Притом всё это всегда происходило в режиме «быстренько-быстренько, не отвлекайся от своего основного проекта, это всё временно». Мда…
В общем, через примерно год я вдруг обнаружил, что:
— Инструментом пользуются — и очень активно — человек 10.
— Они, оказываются. воспринимают эту временную залепуху как один из основных инструментов.
— Никто и не думает включать эту функциональность ни в какой другой инструмент;
— Временный код разбух и превратился в чёрт знает что, а времени на переписывание и приведение в приличный вид никто давать не хочет.
Я, конечно, сам виноват — не уследил. Но и до сих пор я не понимаю до конца — в какой именно момент надо было остановиться, упереться рогом и всё переделать? И как было в необходимости этого убедить начальство?..
Но плохо, когда он этим начинает заниматься в рамках постороннего проекта без необходимости. Ещё раз подчеркну: без необходимости. Разработка толкового фреймворка — довольно дорогое удовольствие, да и не каждый на это способен.
Но, с другой стороны, фреймворк — это просто инструмент, определённый уровень абстракции. Языки программирования это ведь тоже абстракция, верно? Объектная модель в С# — это на самом деле абстракция над CLR кодом. Требуете ли Вы от соискателя заодно и понимания того, как именно работает CLR?
Я не знаю, в других областях, возможно, и по-другому, но, скажем, я не представляю себе написание мало-мальски серьёзного серверного приложения на Яве без использования фреймворков. Да и не очень понятно, зачем…
— Увлекаюсь расширением сознания при помощи натуральных препаратов
Вот это было круто!
Кстати, технологии указываются не только «для балласта». По ним виден кругозор, зачастую профессиональная биография, интересы. Ну и кроме того, некоторые из них могут быть полезны, даже если их знают не очень уверенно.
Про загрузку из банка исходников куда-нибудь не другой сайт лучше и не говорить.