Началось всё, видимо, как обычно, — с Большого взрыва, может, чуть позже. Когда электронов вокруг ядра стало 14. Или в первый день сотворения мира, а именно создания неба и земли (но в тот момент, когда электронов стало 14). Или же на второй день полёта по миру макаронного монстра (ну про 14 электронов вы поняли). А может быть, когда появился тот самый единственный электрон, который сразу везде и нигде (но, как минимум, четырнадцать раз вокруг одного ядра). В тот момент в мире появился кремний. Который сначала в XIX веке именовался силицием, затем в России обрёл крепкое древнегреческое прозвище (в переводе на русский “кремний” — утёс, гора). А через век стал основой для полупроводниковых микросхем и силикона и дал жизнь двум долинам в Калифорнии. Одной — чисто силиконовой (silicon), в России именуемой для дифференциации Кремниевой. Другой — порно-силиконовой (silicone), да и хватит с неё, и так много чести быть опять упомянутой рядом.

В середине XX века за счёт научно-технического прогресса, дальновидности руководства Стэнфордского университета, наличия собственной земли и завещания Лелана Стэнфорда, а также некоторых других факторов, Кремниевая долина близ города Сан-Франциско (Пало-Альто) стала флагманом технического развития в мире. Теперь в каждом государстве, если создают какой-нибудь технопарк, то сразу гордо нарекают его второй кремниевой долиной. Поэтому к XXI веку вторых кремниевых долин насчитывается уже около сотни. Последняя из них, с подачи Дмитрия Анатольевича Медведева тоже Кремниевая, родилась в 2015-м году под Казанью.


Источник: centralandwolfe.com. Кремниевая долина — оригинал

Главная, но не основная часть статьи посвящена как раз Иннополису, однако сначала пройдёмся по каждой более-менее значимой второй Кремниевой долине, чтобы было потом с чем сравнивать.

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

// "Enjoy the Content" — from author with Love 

Эта статья навеяна топиком «Как и насколько быстро вы считаете в уме на элементарном уровне?» и призвана распространить приёмы С.А. Рачинского для устного счёта.
Рачинский был замечательным педагогом, преподававшим в сельских школах в XIX веке и показавшим на собственном опыте, что развить навык быстрого устного счёта можно. Для его учеников не было особой проблемой посчитать подобный пример в уме:

После того, как телефоны стали умнее многих своих владельцев, селфи получили широкое распространение. Делать свои автопортреты в любом, даже самом неподходящем для этого месте, стало любимым занятием пользователей социальных сетей и, прежде всего, Instagram. Тогда мне и пришла идея сделать игру на основе этого тренда. Я и мои коллеги из студии давно занимались разработкой игр на заказ. Был период, когда команда чувствовала себя сильно уставшей от одного из долгосрочных проектов. Я решил отвлечь разработчиков и предложил взять небольшой тайм-аут, чтобы поработать над своим инди-продуктом без заказчиков и издателей — все сделать своими силами.

Пять профессиональных игроков в го не смогли ничего противопоставить натиску AlphaGo

Представители компании DeepMind на днях заявили о том, что игра с Кэ Цзе была последним сражением компьютерной системы AlphaGo с человеком. После победы во всех трех матчах подряд стало понятно, что с компьютером человеку уже не совладать, поэтому для системы играть с другими чемпионами в го просто нет смысла, исход будущих матчей можно считать предрешенным. По словам главы DeepMind Демиса Хассабиса, AlphaGo достигла уже всех возможных высот в го, поэтому время сменить профиль и попробовать себя в новой сфере.

Впервые весь мир услышал о компьютерном игроке в го чуть больше года назад, когда компьютер выиграл со счетом 4:1 у Ли Седоля, одного из чемпионов го. Никто не ожидал такого результата, поскольку эта игра считалась ранее сложной для компьютеров. Здесь огромное количество вариантов выбора хода, гораздо больше, чем в шахматах. По этой причине го считалась прерогативой человека. Но все меняется, компьютеры становятся совершеннее, так что современные программно-аппаратные платформы умеют то, чего не умели компьютеры всего пару-тройку лет назад.

Эта статья – о рисках смены руководства в больших компаниях и характерных явлениях при попытках игнорировать закон эффективного управления собственностью:

Эффективно управлять можно только той собственностью, которую мог бы создать сам.
Кто не может создать, – будет только разрушать!
И.А. Дедюхова, Кодекс Хамурапи

Картинка для привлечения внимания читателей из поколений Y и Z:

Краткое содержание

Новый директор себе в подчиненные и советники пригласит своих «проверенных людей». Увеличение штата топ-менеджеров в условиях фиксированного ФОТ повлечет за собой сокращение рядовых сотрудников на значительный процент.
Новый директор в первую очередь будет сокращать те подразделения, работу которых он не понимает. Под прессом психологического давления руководители этих подразделений возмут на себя обязательства самостоятельно разработать планы по сокращению и принять на себя все риски их реализации.
Сокращения пройдут под флагом повышения эффективности, но для «непонятных директору» подразделений не смогут сформулировать критерии этой эффективности, кроме «минимизации затрат». Цель по минимизации затрат без дополнительных обоснованных ограничений – это цель по уничтожению, и не имеет отношения к настоящей оптимизации.
Отсекая непонятные ему части компании (выводя в аутсорс и т.п.), директор попытается превратить компанию в ту, работу которой он полностью способен понять, которой он в полной мере способен управлять.
Проблему нехватки знаний в технической области новый директор и его команда компенсируют «помощью» от западных консалтинговых компаний. Это приведет к ситуации внешнего управления, причем без всякой ответственности за диктуемые извне решения.
Внешняя и внутренняя отчетность о работе компании до самого конца не будет показывать никаких признаков проблем, т.к. тому, кто принес плохие вести не выдают премию, а рубят голову.

---

В разработку ракеты-носителя "Ангара" и в строительство космодрома Восточный Россия вложила немало. За последние годы в СМИ не раз вспоминали об этих проектах, то в громких обещаниях, то в победных реляциях, то в контексте скандалов. К сожалению, новостей о реальных достижениях было значительно меньше чем бравурной и разоблачительной шумихи. Одна "Ангара" осуществила орбитальный запуск два с половиной года назад, один "Союз" слетал с Восточного год назад. И всё.

Коллеги, нужна помощь тех из вас, кто работает с платформой «1С: Предприятие 8». Платформа 8.3.9 вышла довольно давно, многие из вас уже работают с ней, а некоторые успели попробовать и недавно вышедшую 8.3.10. Примите, пожалуйста, участие в опросе по качеству платформы версий 8.3.8, 8.3.9, 8.3.10: ссылка.

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

Заранее спасибо за помощь!

Всем привет! Я работаю простым разработчиком в одной маленькой, но гордой корейской компании. Как показывает опыт, совместный труд с корейцами редко проходит бесследно: кто-то в ужасе увольняется во время испытательного срока, кто-то учится квасить кимчхи, у кого-то при виде корейца дёргается глаз. Ну а ваша покорная слуга двинулась настолько, что внезапно пошла учиться на востоковеда. Теперь наши корейские друзья для меня — это не только дорогие коллеги, но и объект исследования. Я очень хочу понять, как строить деловые и трудовые отношения с корейцами так, чтобы извлечь как можно больше пользы (кроме вреда). Сегодня я поделюсь кое-какими мыслями на этот счёт.

Корректирующие (или помехоустойчивые) коды — это коды, которые могут обнаружить и, если повезёт, исправить ошибки, возникшие при передаче данных. Даже если вы ничего не слышали о них, то наверняка встречали аббревиатуру CRC в списке файлов в ZIP-архиве или даже надпись ECC на планке памяти. А кто-то, может быть, задумывался, как так получается, что если поцарапать DVD-диск, то данные всё равно считываются без ошибок. Конечно, если царапина не в сантиметр толщиной и не разрезала диск пополам.

Как нетрудно догадаться, ко всему этому причастны корректирующие коды. Собственно, ECC так и расшифровывается — «error-correcting code», то есть «код, исправляющий ошибки». А CRC — это один из алгоритмов, обнаруживающих ошибки в данных. Исправить он их не может, но часто это и не требуется.

Давайте же разберёмся, что это такое.

Для понимания статьи не нужны никакие специальные знания. Достаточно лишь понимать, что такое вектор и матрица, как они перемножаются и как с их помощью записать систему линейных уравнений.

Внимание! Много текста и мало картинок. Я постарался всё объяснить, но без карандаша и бумаги текст может показаться немного запутанным.

Бывает так, что решая одну проблему, выявляешь совсем другую, куда более крупную. Сегодня я расскажу историю о том, как желание оценить эффективность работы антифишинга карт привело нас к стабильному заработку на дому началу борьбы с самой простой, но наиболее распространенной формой фрода.



В прошлом году мы запустили новую версию Яндекс.Браузера с защитой банковских карт от фишинга. Помимо прочих проверок, эта технология оценивает наличие SSL-сертификата. Если пользователь вводит номер карты на HTTP-сайте, то браузер его предупреждает. Логика простая: банки, платежные системы и магазины, которые заботятся о безопасности пользователей, уже давно работают по HTTPS. Это не единственный механизм выявления подозрительных сайтов, но в контексте поста нам будет интересен именно он.

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

Победители принимают заслуженную награду из рук организаторов

Вчера в 18 часов по московскому времени начался финал известнейшего мирового соревнования для программистов, которое называется ACM ICPC. В этом году в соревнованиях участвует более 46 тысяч человек из 103 разных стран. Это даже больше, чем участников Олимпиад — как зимних, так и летних. Напомним, что ICPC проводится каждый год, начиная с 1977 года.

Изначально российские участники были одними из основных претендентов на победу. Этому можно не удивляться, поскольку на предыдущих соревнованиях команды отечественных программистов становились абсолютными чемпионами соревнования 11 раз. При этом 6 раз победителями оказывались программисты из университета ИТМО. Сам университет этим очень гордится, поскольку такое количество побед — это мировой рекорд.

В статье описаны проблемы при проектировании баз данных и немного всего приложения, которые потом с ростом проекта все сложнее и сложнее решить. Моменты, которые важно учесть на этапе дизайна, и не задумываться о них в последствии. Ну или задумываться за чашкой чая и фразой «А помнишь, как мы решили это сделать сразу? Сколько времени мы этим себе сэкономили!», а не с ощущением зубной боли и болезненном вздрагивании при каждом воспоминании. По мере роста системы и числа пользователей, дизайн базы все сложнее и сложнее изменить, и масштаб изменений становится все более глобальным и трудоемким.

Сейчас многие успешные проекты выросли из небольших стартапов, которые потом получили коммерческий успех и стали большими международными компаниями. Такая возможность роста появилась в последние 20 лет, в основном благодаря интернету и эффекту «стирания границ». Появились глобальные интернет-приложения и мобильные приложения, которые могут быть использованы в любой стране. Ранее, чаще всего, если приложение должно было быть международным проектом, оно и проектировалось уже сразу с учетом такого требования. Конечно, можно воспользоваться эволюционным подходом, и по мере роста проекта добавлять в него необходимые функции и масшатибирование. Но для облегчения внедрения дальнейших изменений, необходимо сразу учитывать масштаб некоторых базовых функций, изменить которые в дальнейшем сложно.

Я работала в 2х стартап-проектах, которые выстрелили и выросли в большие компании с миллионами пользователей из маленьких региональных проектов, и сейчас являются высоконагруженными. К моему удивлению я увидела, что есть много общих проблем, хотя приложения писались разными командами и для разных пользователей. Видны общие проблемы в базах данных, которые являются наследием стартапа, такими детскими проблемами роста, которые показывают, что изначально проект был запланирован маленьким.

В этой статье мы попытаемся рассказать, как с помощью удаленных и территориально распределенных команд мы наладили процесс выпуска прикладных решений, расширяющих функциональность нашего продукта «1С:ERP Управление предприятием 2».

В детстве мы постигаем премудрости жизни через игру. Это важнейший элемент развития личности, социальных навыков, получения знаний об окружающем мире. Игры — хороший «контейнер» для донесения и закрепления каких-либо знаний. Яркий пример — игры, в которых нужно писать код. Наверняка все вы о них слышали, а в некоторые даже играли. Их первичная задача — развлечь людей, уже владеющих навыками программирования, но они могут использоваться и для обучения. Эти игры помогут освежить свои знания по тому или иному языку, отвлечься и заняться более простой алгоритмической задачей.

[Когда график поджимает и проект уже пора выпускать, программисты могут прибегать к грязным трюкам, чтобы уже наконец выпихнуть игру за дверь. В этой статье собрано девять примеров таких «костылей» из реальной жизни.]

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

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

Выбрать всего пять книг оказалось непростой задачей. Каждый раз, добавляя книгу в список, я задавал вопрос: почему именно эта? Я решил выделить пять ключевых направлений, в которых должен развиваться разработчик, и привести по одному примеру книги в каждом из них.

Уверен, вы сможете предложить варианты не хуже, а возможно, и лучше. Я называю книги, впечатлившие меня, или те, с которыми сталкивался чаще. В любом случае, их будет полезно прочесть как начинающим разработчикам, так и тем, кто уже обладает достаточным опытом.

Привет, Хабр! Сегодня я решила поделиться с вами транскриптом первого выпуска подкаста «Правила игры», в котором я общаюсь с юристами и экспертами по налогам.

25 апреля Коллегия по экономическим спорам Верховного Суда РФ приняла определение, в котором признала, что фотографии, взятые из Интернета, в некоторых случаях могут использоваться на сайтах без согласия правообладателей и без выплаты им вознаграждения. «Ну, теперь наконец-то можно брать чужие фотки, Верховный Суд же разрешил!», — такие утверждения стали то и дело появляться на профессиональных форумах и в комментариях. Здесь надо сделать важную оговорку: только в некоторых случаях, причем довольно ограниченных. В каких конкретно – разбираемся в данном материале.

Наверняка вы знаете, кто такой Джон Скит: №1 на Stack Overflow, автор C# in Depth (одной из лучших книг по .NET), разработчик в Google и 14-кратный MVP. Разработчиков такого масштаба не так много, хватит двух порядков, чтобы их всех перечислить. 19-20 мая Джон приедет в Петербург и выступит на DotNext 2017 Piter.

Мне удалось пообщаться с Джоном и взять у него большое интервью по поводу судьбы .NET, .NET Core, нововведений в C# 7 и общем уровне развития среднего разработчика в 2017 году.



Если говорить конкретно, то обсудили следующие вопросы:

• Общее направление развития .NET и ошибки Microsoft;
• Чего ждать от .NET Core в ближайшем будущем;
• Стоит ли мигрировать на .NET Core, если у вас легаси на .NET Framework;
• Проблемы и победы .NET на поприще кроссплатформенности;
• Java vs .NET на рынке enterprise решений;
• Чем хороши tuples и pattern matching в С# 7, а что стоило сделать иначе;
• Небольшие, но приятные фичи C# 7;
• Деградация сообщества разработчиков (и есть ли она);
• Правильный подход к диагностике багов и постановке правильных вопросов на SO;
• Гайд по изучению новых языков и платформ;
• Проблемы с базовыми типами: числа, текст, дата и время;

Интервью получилось очень большое, но мне кажется, оно стоит каждой потраченной на него минуты.