Читайте внимательнее, и не только свои комментарии.
Кстати вчерашний студент, который бьет себя в грудь и кричит что он любит паттерны, правильные архитектуры, и вообще он за все хорошее и против всего плохого, вот он имеет правильное отношение для «инженера-архитектора»?
Думаю, что все зависит от уровня владения предметом и навыков — результат определяется как уровнем теоретической подготовки, так и практическим опытом. Мне сложно судить про абстрактных студентов, у нас работает несколько старшекурсников, отличные ребята, у которых за плечами уже с десяток проектов.
Расскажите, приходится-ли вам на работе сталкиваться с однотипными проблемами и используете-ли вы в таких случаях какие-то типовые решения? Как вы делитесь ими с коллегами?
Возможно, занимаясь свою всю жизнь такими, не очень важными делами, вы не погибнете от травм, полученных в автокатастрофе, но при жизни вам не хватит времени на разработку суперкомпьютеров. bash.im/quote/401459
Паттерны это из области архитектуры, а не программирования. Они больше полезны при проектировании приложения, чем его реализации. Качество проектирования играет меньшую роль на этапе разработки, но становится ключевым на этапе поддержки и развития.
Условно, в мире вещей есть такой конструкторский прием — контрагайка, который при вибрациях повышает надежность, не давая соединению развинчиваться. Технически, это когда на один болт накручивается вместо одной гайки — две. Причем, это могут быть абсолютно одинаковые гайки. Т.е. с точки зрения слесаря, задача которого изготовить гайки, между гайками нет ни какой разницы. Разница заметна только на уровне инженера. Слесари могут искренне «не понимать», зачем нужны все эти конструкторские приемы, когда в результате от них требуется одно и то же.
Так вот, отношение к разработчика паттернам на собеседовании показывает в какой роли он себя представляет «слесаря-кодера» или «инженера-архитектора», и соответственно определяет типы задач, решение которых ему можно будет доверить.
Наверняка, о чем-то подобном мечтали и разработчики Sliverlite. Думаю здесь работает эффект «вавилонской башни» (я имею ввиду ту часть этой истории, когда люди говорили на одном языке, а потом их наказали). WEB основан на сравнительно небольшом множестве простых концепций, поддержанных в открытых стандартах. Мне кажется, что в таких масштабах профит от использования единого для всех языка перевешивает все недостатки (даже на сервер js притащили). Мультиязычность неплохо работает в огороженных мирках, но в массе, дробит сообщество и увеличивает хаос.
Ежегодный релиз-цикл, необратимые изменения начинают действовать со следующего релиза.
На моей памяти, индустрия постоянно предпринимала попытки избавится от JS. Разработчики разных браузеров то и дело встраивали поддержку других языков, предлагая сообществу лучшие альтернативы. Но эта стратегия ни разу не принесла успеха. Подавляющее большинство продолжало упорно использовать JavaScript. Похоже, что на этот раз решили действовать по-другому, превратив JavaScript в Perl (как показала практика оно потом само дохнет).
Имхо, JS, несмотря на всю свою несуразность и изначальные просчеты, получил такое распространение и популярность благодаря простоте языка, четкому стандарту, не ломающейся годами совместимости и как следствие интероперабельности кода. Все это очень удобно на практике.
Теперь, наряду некоторым набором определенно полезных вещей, в спецификацию вбросили адову кучу синтаксических трюков, что усложняет язык в разы. Снаружи добавилось интсрументирование — трансплитеры уже необходимость. Если они собираются менять и спецификацию каждый год, то скоро эпохе JS придет конец.
В статье наглядно описан процесс рефакторинга кода, начиная с описания проблемы и постановки задачи по существу. Подробно объясняются мотивации для каждого действия, локальные засады и решения. Класс!
В последнем видео, мысль про то, что все надо делать хорошо и не надо делать плохо, проста и понятна. Качественные определения удобно использовать для описания ситуации, в целом. Но как и любые другие качественные определения, эти понятия зависят от контекста и не поддаются прямым количественным измерениям. Отсюда, в подобной риторике с «программистами», часто возникают сложности, поскольку их пытливый ум начинает искать в словах какой-то формализм и не находя его, расценивает произнесенное как попытку агрессии (показателен коммент из зала про священную войну между «бизнесом» и «разработкой»).
Загляните в исходники mdl (какой-нибудь кнопки например, github.com/google/material-design-lite/blob/master/src/button/_button.scss). Они спокойно используют каскады между b-e-m в любых комбинациях, переопределяют стили других «блоков». По сути, это обычный CSS, как в boostrap, foundation и т.п., только с необыкновенно длинющими названиями классов.
Создается ощущение, что БЭМ в версте стал сродни MVC в программировании, в том смысле, что каждый находит его во всем, что видит, но понимает по-своему. Когда я читаю github.com/google/material-design-lite/wiki/Understanding-BEM, в душу начинает закрадываться сомнение, что это тот же БЭМ, который у Яндекса.
Когда смотришь на конечный результат, о методологиях сложно судить. Несоответствия могут быть тупо результатом наслоения работы разных людей, в разное время, которые придерживались разных подходов.
Если уж все люди на планете знакомы друг с другом через шесть рукопожатий максимум, то в рамках отдельно взятого города что-то общее с Яндексом имеют, наверное, через одного. По-видимому, кому-то очень хотелось чтобы так случилось.
Любая практическая методология, предполагает некий алгоритм успеха. Иными словами, если в заданных условиях делать все согласно методологии, то желаемый результат будет достигнут. В этом их польза методологий.
Многие покупаются на БЭМ-методологию в расчете, дескать, вот щаз как внедрим и все станет «зашибись», как Яндексе. Проблемы возникают из-за того, что многие так же забывают, что как и любая практическая методология, БЭМ имеет свою конкретную область применения — мало кто понимает насколько все «зашибись» в Яндексе, почему так, как устроена разработка и какова роль в этом БЭМ.
Эффективность решения задач повышается за счет использования подходящих технологий, накопления опыта, повторного использования кода и автоматизации. Методологии же нужны, чтобы создавать технологии. В Яндексе примерно так все и устроено: одни люди занимаются разработкой технологий следуя БЭМ и прочим методологиям — кодят инструментарий, компоненты, пишут документацию, рассказывают на конференциях как все круто, другие — решают с помощью них практические задачи.
Если вы не Яндекс, то у вас наверняка совершенно другие исходные условия, и и поэтому БЭМ-методология работать не будет. Но такой вывод следует из определения, поэтому является банальным и ни кому не интересным.
Конкретно с мелкими int тут другая история. В классическом CPython целочисленные значения от -5 до 256 представляются ссылками на массив констант. Поэтому переменные с одинаковыми значениями в диапазоне [-5, 256] содержат одинаковые ссылки.
>>> 256 is 256
True
>>> a = 256
>>> b = 256
>>> a is b
True
Для остальных целочисленных значений такое условие уже не выполняется:
>>> 257 is 257
True
>>> a = 257
>>> b = 257
>>> a is b
False
=) Наверняка, свой долг по ипотеке вы уменьшаете после каждой з/п, которую вам вовремя платит фирма из денег, которые зарабатывает на том, что делает все вовремя. Таков алгоритм, вы же разбираетесь в алгоритмах. Если работу не делать вовремя, откуда фирма сможет вовремя взять деньги на очередную з/п, чтобы вы и ваши коллеги могли и дальше гасить свои ипотечные долги, как думаете?
Клип в стиле популярного жанра Science-клоунады. «информация = порядок, информация = энтропия», и т.п. глупости, в конце фееричные выводы про Вселенную.
Способы монетизации, наверняка, прорабатывались сильно заранее. Но с таким количеством технических отказов не до монетизации. Почему выкатили сырую версию? Как знать. Возможно, кто-то просто «поинтересовался» у команды (вложить $80 млн. и потом еще 2 года разработки в 70 человек — любопытно же, во что. А начало октября это внезапно начало IV квартала, как известно последнего до конца финансового года). Возможно, «горел» какой-нибудь реальный контракт, для которого функциональность «нового КП» должна быть уже в паблике. Возможно, кто-то посчитал Too big to fail.
Вам знакомо такое чувство, когда все делаешь «так», но в результате что-то не срастается? Например, покупаешь что-нибудь хорошее, а потом осознаешь, что купил не то.
Кинопоиск (как и IMDb ;)) это энциклопедия. Хорошая энциклопедия. Сюда люди приходят читать о кино и всём, что с ним связано, а не смотреть. Только Яндекс в последнее время, похоже, сознательно уходит от сервисов с моделями, основанными на генерации контента (помянем народ.ру, ярушечку, мой круг, авто.ру,… светлая память), в пользу улучшения доступности чужого. Но чужого контента о кино, сравнимого по качеству нет ни у кого, и не предвидится.
А еще есть, к примеру, RuTracker, где на долю кино так же приходится изрядная доля контента. Описания к раздачам нередко оформлены весьма и весьма качественно. Почти как на Кинопоиске. Почти. Ведь, основная аудитория, все же, вспоминает об этом сервисе, когда хочет посмотреть кино, а не читать аннотации. Основная фишка трекеров в доступности.
«Новый кинопоиск» Яндекса больше про посмотреть, а не про почитать. Этим он принципиально отличается от старого Кинопоиска, и идеологически ближе к RuTracker'у. На мой взгляд, они просто не тот сервис купили, чтобы улучшать. :)
Думаю, что все зависит от уровня владения предметом и навыков — результат определяется как уровнем теоретической подготовки, так и практическим опытом. Мне сложно судить про абстрактных студентов, у нас работает несколько старшекурсников, отличные ребята, у которых за плечами уже с десяток проектов.
Расскажите, приходится-ли вам на работе сталкиваться с однотипными проблемами и используете-ли вы в таких случаях какие-то типовые решения? Как вы делитесь ими с коллегами?
Условно, в мире вещей есть такой конструкторский прием — контрагайка, который при вибрациях повышает надежность, не давая соединению развинчиваться. Технически, это когда на один болт накручивается вместо одной гайки — две. Причем, это могут быть абсолютно одинаковые гайки. Т.е. с точки зрения слесаря, задача которого изготовить гайки, между гайками нет ни какой разницы. Разница заметна только на уровне инженера. Слесари могут искренне «не понимать», зачем нужны все эти конструкторские приемы, когда в результате от них требуется одно и то же.
Так вот, отношение к разработчика паттернам на собеседовании показывает в какой роли он себя представляет «слесаря-кодера» или «инженера-архитектора», и соответственно определяет типы задач, решение которых ему можно будет доверить.
На моей памяти, индустрия постоянно предпринимала попытки избавится от JS. Разработчики разных браузеров то и дело встраивали поддержку других языков, предлагая сообществу лучшие альтернативы. Но эта стратегия ни разу не принесла успеха. Подавляющее большинство продолжало упорно использовать JavaScript. Похоже, что на этот раз решили действовать по-другому, превратив JavaScript в Perl (как показала практика оно потом само дохнет).
Имхо, JS, несмотря на всю свою несуразность и изначальные просчеты, получил такое распространение и популярность благодаря простоте языка, четкому стандарту, не ломающейся годами совместимости и как следствие интероперабельности кода. Все это очень удобно на практике.
Теперь, наряду некоторым набором определенно полезных вещей, в спецификацию вбросили адову кучу синтаксических трюков, что усложняет язык в разы. Снаружи добавилось интсрументирование — трансплитеры уже необходимость. Если они собираются менять и спецификацию каждый год, то скоро эпохе JS придет конец.
Многие покупаются на БЭМ-методологию в расчете, дескать, вот щаз как внедрим и все станет «зашибись», как Яндексе. Проблемы возникают из-за того, что многие так же забывают, что как и любая практическая методология, БЭМ имеет свою конкретную область применения — мало кто понимает насколько все «зашибись» в Яндексе, почему так, как устроена разработка и какова роль в этом БЭМ.
Эффективность решения задач повышается за счет использования подходящих технологий, накопления опыта, повторного использования кода и автоматизации. Методологии же нужны, чтобы создавать технологии. В Яндексе примерно так все и устроено: одни люди занимаются разработкой технологий следуя БЭМ и прочим методологиям — кодят инструментарий, компоненты, пишут документацию, рассказывают на конференциях как все круто, другие — решают с помощью них практические задачи.
Если вы не Яндекс, то у вас наверняка совершенно другие исходные условия, и и поэтому БЭМ-методология работать не будет. Но такой вывод следует из определения, поэтому является банальным и ни кому не интересным.
Для остальных целочисленных значений такое условие уже не выполняется:
Эта особенность поддерживается на уровне операций:
Кинопоиск (как и IMDb ;)) это энциклопедия. Хорошая энциклопедия. Сюда люди приходят читать о кино и всём, что с ним связано, а не смотреть. Только Яндекс в последнее время, похоже, сознательно уходит от сервисов с моделями, основанными на генерации контента (помянем народ.ру, ярушечку, мой круг, авто.ру,… светлая память), в пользу улучшения доступности чужого. Но чужого контента о кино, сравнимого по качеству нет ни у кого, и не предвидится.
А еще есть, к примеру, RuTracker, где на долю кино так же приходится изрядная доля контента. Описания к раздачам нередко оформлены весьма и весьма качественно. Почти как на Кинопоиске. Почти. Ведь, основная аудитория, все же, вспоминает об этом сервисе, когда хочет посмотреть кино, а не читать аннотации. Основная фишка трекеров в доступности.
«Новый кинопоиск» Яндекса больше про посмотреть, а не про почитать. Этим он принципиально отличается от старого Кинопоиска, и идеологически ближе к RuTracker'у. На мой взгляд, они просто не тот сервис купили, чтобы улучшать. :)