Добавлю также, что артикли в названиях — плохой стиль, так как а) замусоривает само имя б) не несет никакого смысла.
Вообще, стоит очень строго придерживаться naming'а, и если бы функция, предназначенная для кидания некоего стандартного exception'а (на пример, в Java), называлась бы throwAwayAnException, у меня был бы точно вопрос к качеству именования в таком PR.
Наверно, между теми, кто уже ценит важность навыков профессионального (да и человеческого тоже) общения (читай, профессиональная этика), и теми, кто еще этого не делает. Как у сис.админов в бородатом анекдоте — "одни уже делают бэкапы, а другие еще нет". Это как с гигиеной. Мы можем сколько угодно отрицать ее важность, игнорируя правила, но, в конечном итоге, за последующие болячки все равно отвечать будем мы, т.к "не для нас эти правила писаны, ибо мы умнее".
Есть такое, но разве бинарное дерево поиска не решает эту проблему?
Скорее не бинарное, а 2-3-4 дерево, но это так — технические подробности.
Что касается распределённых, то разве нельзя держать копии на всех машинах
И получить головную боль в виде поддержки консистентности данных пользователей?
Но если пользователи используют действительно уникальные пароли, а не «feezbuzz» — что там может совпасть? -_-
Это все скорее слишком оптимистичные сценарии, не все готовы хранить и запоминать пароли на 64+ символа с равным соотношением спец. символов, цифр, букв, и уж тем более еще меньший процент готов приводить свои пароли в соотвествие с техническими рекомендациями по безопасности. Чаще запоминают мнемонические пароли, или пароли как ответы на вопросы (день рождения, имя жены, домашнего животного, и.т.д)
Мы исходим из предположения, что злоумышленник может получить такую возможность)
Сознательными могут быть и злоумышленники, и обычные пользователи, также как и несознательными. Не стоит уповать на одни только успешные сценарии поведения пользователя
Навскидку видится больше минусов, чем плюсов. Т.е настолько нестандартно, что использовать можно (на свой страх и риск) на ресурсах агрегаторах новостей например,
где важна возможность полистать ленту, посрать в комментариях, т.е нет данных кредиток и прочей компрометирующей информации.
Плюсы:
"Удобство" аутентификации. Нет пароля, пожалуй единственная фишка подхода. Жизнеспособно для ресурсов, не компрометирующих данные пользователя
Минусы:
Неудобно эргономически, слишком много действий на вход
Неудобно для клиента почтового сервиса, да и для самого сервиса в частности. Замусоривается пространство почтового ящика, при этом для почтового сервиса такие аутентификационнные письма создадут дополнительную нагрузку по траффику
Уязвимость к атакам session fixation. Здесь стоит вопрос доверия к самой ссылке. Можно банально попастся на письмо аналогичного содержания от хакеров, только с немного другим токеном. Вариантов — масса.
Можно просто подарить ID сессии злоумышенникам, либо зайти 'нетуда' и слить еще и данные других доменов через клиентский XSS.
Учитывая то, что пользователь будет уходить по такой ссылке, например, с gmail.com, это наверняка будет отслежено гуглом — банальный запрос на тот же домен почтового сервиса с последующей отдачей ответа 301. Здесь всплывает опасность MiTM.
Это решаемо. Например, когда пользователь устанавливает пароль (при регистрации или меняет старый), можно проверять, не используется ли хеш пароля другим аккаунтом. Правда, придётся предупреждать и владельца другого аккаунта (и принять временные меры для его защиты) =)
Во-первых, это затратно для баз с большим кол-вом пользователей. Тем более для распределенных
Во-вторых речь шла о рисках "похожести" двух паролей когда пользователь хочет ввести feezbuzz, но ошибается и вводит fezbuzz, и логинится под другим аккаунтом. Вот как раз наличие дополнительного user id (еmail или обычный логин) нивелирует этот риск
Да, это к тому же накладывает дополнительное требование на минимальное расстояние редактирования (расстояние Левенштейна) между двумя паролями, что во сто крат хуже обычного требования на длину пароля. Что если пользователь ошибется в одном символе, и зайдет под другой учеткой?
Да и при использовании тривиальных схем хэширования у нас есть шанс появления паролей-коллизий, не привязанных ни к одному email.
С аппликэйшн сервером тебе нет необходимости знать где какая база, как к тебе ходят пользователи, по какому протоколу, думать где у тебя продакшен сервер, а где боевой и т.д. ты просто занят бизнес логикой.
Да, это только с одной оговоркой — если все заранее настроено, и работает как часы
Большинство компаний – это не обучающе-развивающие площадки для программистов. Это – бизнесы, которые работают, и именно благодаря этому в них можем работать мы. Кстати, лично мне это сочетание – бизнес и технология – очень нравится. Мне нравится работать над вещами, которые изменяют мир. И многим инженерам с которыми я общалась на эту тему – тоже.
Как раз это и плохо, в том же Google, 20% времени компания выделяла на развитие своих сотрудников. Неужели все изменилось даже там? Т.е компания не заинтересована в развитии сотрудников, а только в зарабатывании денег? Человеческий капитал — самый ценный как никак.
Старайтесь описывать дизайн систем, над которыми вы будете работать, заранее (aka пишите design docs)
Описан какой-то водопад, в нашем то современном экстремально-итеративном мире. Системы зачастую проектируется итерациями, а не за один вечер. У Макконела это хорошо описано. Проработанный дизайн системы с нуля — редкость, и не присущ большинству современных процессов разработки.
Всегда ищите и берите простые и одновременно важные проекты, когда вам предоставится такая возможность.
Это из разряда — Android-приложение для заказа пиццы? Что-то на уровне дешевых советов о том, как поднять свой стартап.
Это – Результат
Мне сразу вспомнился лемминг-вождь из Мадагаскара, отчитывающих своих подчиненных ;)
Говорите о своей работе (можно со слайдами)
Зачем мне рассказывать каждому (!) о том, что я делаю каждый день. Для этого есть issue tracking и логгирование времени. Если речь идет про донесение каких-то своих идей людям в компании, то для это вовсе не нужны слайды — пустая трата времени, достаточно доски и маркера. Если вы не можете донести свои мысли и идеи без слайдов, значит плохо их формулируете. Давний принцип педагогики кстати — если не можешь донести сложные вещи простыми словами до первоклассника, значит ты "плохой" педагог :)
Стеб применим вообще к любым проявлениям т.н «серебряных пуль» — подходов или методологий, решающих любые проблемы исполнителя, и проблема в них всегда одна — неумение, ну или нежелание исполнителей применить такие подходы с умом, т.е не так как сказано «в телевизоре», а по контексту ситуации.
Три раза "Ха" подобным общественным инициативам, стремящимся привить так называемое "Креативное мышление" в областях, с процессом творчества имеющих мало чего общего — Копирайтинг, HR, Управление, коммуникации и иже с ними.
Статью вы явно не читали
Софт-скилл #1 для каждого разработчика — будь как твой батя (инженер)
Вы часто используете Object.clone()?
В статье уже есть пометка :)
Добавлю также, что артикли в названиях — плохой стиль, так как а) замусоривает само имя б) не несет никакого смысла.
Вообще, стоит очень строго придерживаться naming'а, и если бы функция, предназначенная для кидания некоего стандартного exception'а (на пример, в Java), называлась бы throwAwayAnException, у меня был бы точно вопрос к качеству именования в таком PR.
Наверно, между теми, кто уже ценит важность навыков профессионального (да и человеческого тоже) общения (читай, профессиональная этика), и теми, кто еще этого не делает. Как у сис.админов в бородатом анекдоте — "одни уже делают бэкапы, а другие еще нет". Это как с гигиеной. Мы можем сколько угодно отрицать ее важность, игнорируя правила, но, в конечном итоге, за последующие болячки все равно отвечать будем мы, т.к "не для нас эти правила писаны, ибо мы умнее".
Возникает ощущение по последним статьям на хабре, что выяснение отношений между обоими мирами — тема, которая волнует многих.
Похоже, принцип бритвы Оккама нарушен уже в самой статье, хотя и упоминается в ней)
Под такой тип кода есть даже специальный термин: "китайский код" :)
Скорее не бинарное, а 2-3-4 дерево, но это так — технические подробности.
И получить головную боль в виде поддержки консистентности данных пользователей?
Это все скорее слишком оптимистичные сценарии, не все готовы хранить и запоминать пароли на 64+ символа с равным соотношением спец. символов, цифр, букв, и уж тем более еще меньший процент готов приводить свои пароли в соотвествие с техническими рекомендациями по безопасности. Чаще запоминают мнемонические пароли, или пароли как ответы на вопросы (день рождения, имя жены, домашнего животного, и.т.д)
Мы исходим из предположения, что злоумышленник может получить такую возможность)
Сознательными могут быть и злоумышленники, и обычные пользователи, также как и несознательными. Не стоит уповать на одни только успешные сценарии поведения пользователя
Навскидку видится больше минусов, чем плюсов. Т.е настолько нестандартно, что использовать можно (на свой страх и риск) на ресурсах агрегаторах новостей например,
где важна возможность полистать ленту, посрать в комментариях, т.е нет данных кредиток и прочей компрометирующей информации.
Плюсы:
Минусы:
Можно просто подарить ID сессии злоумышенникам, либо зайти 'нетуда' и слить еще и данные других доменов через клиентский XSS.
Во-первых, это затратно для баз с большим кол-вом пользователей. Тем более для распределенных
Во-вторых речь шла о рисках "похожести" двух паролей когда пользователь хочет ввести feezbuzz, но ошибается и вводит fezbuzz, и логинится под другим аккаунтом. Вот как раз наличие дополнительного user id (еmail или обычный логин) нивелирует этот риск
Да, это к тому же накладывает дополнительное требование на минимальное расстояние редактирования (расстояние Левенштейна) между двумя паролями, что во сто крат хуже обычного требования на длину пароля. Что если пользователь ошибется в одном символе, и зайдет под другой учеткой?
Да и при использовании тривиальных схем хэширования у нас есть шанс появления паролей-коллизий, не привязанных ни к одному email.
Да, это только с одной оговоркой — если все заранее настроено, и работает как часы
Как раз это и плохо, в том же Google, 20% времени компания выделяла на развитие своих сотрудников. Неужели все изменилось даже там? Т.е компания не заинтересована в развитии сотрудников, а только в зарабатывании денег? Человеческий капитал — самый ценный как никак.
Описан какой-то водопад, в нашем то современном экстремально-итеративном мире. Системы зачастую проектируется итерациями, а не за один вечер. У Макконела это хорошо описано. Проработанный дизайн системы с нуля — редкость, и не присущ большинству современных процессов разработки.
Это из разряда — Android-приложение для заказа пиццы? Что-то на уровне дешевых советов о том, как поднять свой стартап.
Мне сразу вспомнился лемминг-вождь из Мадагаскара, отчитывающих своих подчиненных ;)
Зачем мне рассказывать каждому (!) о том, что я делаю каждый день. Для этого есть issue tracking и логгирование времени. Если речь идет про донесение каких-то своих идей людям в компании, то для это вовсе не нужны слайды — пустая трата времени, достаточно доски и маркера. Если вы не можете донести свои мысли и идеи без слайдов, значит плохо их формулируете. Давний принцип педагогики кстати — если не можешь донести сложные вещи простыми словами до первоклассника, значит ты "плохой" педагог :)
Ну, глядя на тенденцию обучения программированию с младых ногтей, думаю что это не будет проблемой в ближайшем будущем
Три раза "Ха" подобным общественным инициативам, стремящимся привить так называемое "Креативное мышление" в областях, с процессом творчества имеющих мало чего общего — Копирайтинг, HR, Управление, коммуникации и иже с ними.