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

Всем привет.

С середины 2016 года мы проектируем и разрабатываем новое поколение платформы. Принципиальное отличие от первого поколения — поддержка API "тонкого" клиента. Если старая платформа предполагает, что на клиента при запуске загружается метаинформация о всем контенте, который доступен для абонента, то новая платформа должна отдавать срезы данных отфильтрованные и отсортированы для отображения на каждом экране/странице.

Высокоуровневая архитектура на уровне хранения данных внутри системы — постоянное хранение всех данных в централизованном реляционном SQL хранилище. Выбор пал на Postgres, тут никаких откровений. В качестве основного языка для разработки — выбрал golang.

У системы порядка 10м пользователей. Мы посчитали, что с учетом профиля теле-смотрения, 10М пользователей может дать сотни тысяч RPS на всю систему.

Это означает, что запросы от клиентов и близко не стоит подпускать к реляционной SQL БД без кэширования, а между SQL БД и клиентами должен быть хороший кэш.

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

С приобретением нового телевизора возник вопрос, какую приставку для него брать. Возможностей Chromecast уже не хватало и хотелось полноценный медиацентр на Kodi. Телевизор со SmartTV покупать не вариант — Kodi можно установить только на Android (из SmartTV платформ), а к нему я отношусь без особой любви, к тому же он уже внутри телевизора, а не в отдельной коробке, которую можно безбоязненно перепрошивать. Ну а зачем мне полноразмерный Android, со всеми его сервисами и программами в виртуальной машине, без полноценного GNU/Linux окружения и, скорее всего, без обновлений? По той же причине также были отметены многочисленные готовые медиацентры на Android, хотя та же приставка от Xiaomi довольно хороша. Можно было бы подумать насчёт SmartTV на TizenOS, но для него нет Kodi.

В сегодняшнем материале мы собрали одни из наиболее популярных книг, отобранных самими разработчиками — резидентами Reddit, Quora, Stack Exchange, Stack Overflow и Hacker News.

В нашу подборку попали работы по популярным языкам программирования, проектированию ПО, работе с Linux-системами, сборники практических советов для разработчиков — от начинающих, до опытных. Объединяют эту подборку высокие оценки самих программистов, которым эти книги помогали на разных этапах их карьеры.

Несмотря на проблемы глобального потепления, в западном дизайн-сообществе вновь публикуются новые утилиты, плагины и сервисы, которые призваны улучшить workflow дизайнера и разработчика. В этом списке я привожу 21 нужную ссылку на новые штуки, которые были высоко оценены сообществом!

Типы System.Tuple были введены в .NET 4.0 с двумя существенными недостатками:

1. Типы кортежей являются классами;
2. Не существует языковой поддержки для их создания/деконструкции (deconstruction).

Чтобы решить эти проблемы, в C# 7 представлена новая возможность языка, а также новое семейство типов (*).

Сегодня, если вам нужно склеить два значения, чтобы вернуть их из функции или поместить два значения в хэш-набор, вы можете использовать типы System.ValueTuple и создать их с помощью удобного синтаксиса:

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

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

У программистов не было ни гита, ни джетбрейнса, ни даже ноутпад++. Первую программу автор писал в дрянном редакторе бейсика. Мы думали, что крутость программиста зависит от того, с какой скоростью он печатает. Мы думали, что крутость компьютера можно измерить тем, сколько раз на него можно будет скопировать Syphon Filter.

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

Собеседование — это игра. Иногда игра бывает интересной и в чём-то продуктивной, иногда она превращается в фарс. Иногда оценивают прошлое, иногда — настоящее. Есть некоторое общее понимание того, что нужно спрашивать, и нет совершенно никакого материального обоснования, почему необходимо спрашивать именно это. «Потому что мы будем как Гугл», «потому что не ясно, что вообще делать», «ведь нужно что-то спрашивать».

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

Будет больно. Потому что будет правда.

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

Автор — из старой школы. По разным причинам. Мне нравится заниматься «всем», помогать себе и компании, и я рассчитываю на отдачу — не только, и не столько, на финансовую. Я постоянно учусь. Но не только своей «основной», узкой специальности (=программирование), за которую платят, и ниже объясню, почему…

Недавно я столкнулся с проблемой, известной как «переученность». Такое бывает, когда ты переростаешь вакансию «вширь», а компания не может никак это использовать. Тогда ты ломишься в стартапы, стараясь самовыразиться, ищешь варианты, разговариваешь с руководством (тут мне повезло), или просто уходишь.

Дальше я постараюсь обобщить личный и известный мне опыт по этой проблеме.

Многие из нас бывали на айтишных конференциях. А если не бывали, то наверняка смотрели трансляции, записи или читали расшифровки докладов на Хабре. А вы знаете, какие доклады становятся хитами даже на самых-самых хардкорных мероприятиях? Внутренности сложных технологий? Нет. DevOps? Отнюдь. Чаще всего приз зрительских симпатий берут так называемые доклады-кейноуты — презентации людей, вовсе не обязательно связанных с IT. Дело не в красивой презентации и даже не в харизме докладчика, а в том, что эти ребята знают секрет SUCCES. Нет, мы не опечатались.

Источник: Duran

«Седой странник» пополняет запасы воды из артезианского источника в пустыне NT, насос питается ветряком

В Австралии очень длинный средний срок жизни — 85 лет. Для сравнения — у нас только недавно он перешагнул 70, до этого был в районе 65. Пенсия наступает в 55-65 лет. Остаётся ещё примерно 20-30 лет на то, чтобы что-то делать.

Представьте: вам 55, пенсии нормально хватает на жизнь без излишеств, дети уже разъехались. Вы живёте в своём доме где-то за городом и думаете, что бы такое сделать. Ну а дальше начинается странное. Настолько, что они смогли во многом изменить образ жизни очень многих мелких поселений.

Итак, дом сдаётся в аренду, и бабушки с дедушками покупают себе дом-на-колёсах. Это или прицеп к внедорожнику с контейнером-домом, или фургон типа «сухопутная яхта» или даже переделанный автобус. И едут в «кругосветку» по Австралии — это легко, потому что весь континент — это одна страна (раза в два меньше России), и есть кольцевая дорога вокруг. На годик-полтора, как поначалу думают эти прекрасные люди. И застревают на 10-15 лет.

Привет, Хабр! Давно у нас в блоге не было расшифровок мастер-классов. Исправляемся. В этом посте вас ждет грандиозное путешествие в мир шрифтов от древнейших времен до наших дней. Если вы хотите понять, каким образом шрифты влияют на наши эмоции и наконец научиться отличать гуманистический гротеск от ленточной антиквы — добро пожаловать под кат. И да, там очень много картинок. Передаем слово автору.

---

Шутка, написанная гарнитурой Times, на 10 % смешнее той, что написана гарнитурой Arial. Почему? Чёрт знает. Лучшее объяснение, которое я видел: юмор ассоциируется с агрессией, с остротой, с остроумием — а Times выглядит более острым, чем Arial.

Ещё один любопытный эксперимент, в котором участвовало 45 тыс. человек. Заходишь на сайт, тебе показывают статью Дэвида Дойча, британского физика. В статье автор пишет, что сегодня очень трудно внезапно умереть. Например, от инфекционного заболевания или в уличной драке. Лет сто назад это случалось намного чаще. Главный вывод статьи — сейчас мир безопасен как никогда. В среднем, конечно, ведь где-то постоянно идут локальные военные конфликты.

Оптимизация производительности издавна не даёт покоя разработчикам, представляясь своеобразным «золотым ключиком» к интересным решениям и хорошему послужном списку. Большую обзорную экскурсию по ключевым вехам оптимизации больших проектов  – от общих принципов до ловушек и противоречий —  на прошедшем JPoint 2017 провёл Алексей Шипилёв, эксперт по производительности.



Под катом — расшифровка его доклада.

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

Давайте подумаем и обозначим проблемы, которые могут возникнуть в процессе разделения задач, и способы их решения. В этом посте будут рассмотрены основные принципы декомпозиции задач при работе в команде. Меня зовут Илья Агеев, я – глава QA в Badoo. Сегодня расскажу, как workflow влияет на декомпозицию, насколько отличаются тестирование и выкладка задач, которые появляются в результате декомпозиции, и каких правил стоит придерживаться, чтобы процесс разработки проходил гладко для всех участников.

Метод Уэлфорда — простой и эффективный способ для вычисления средних, дисперсий, ковариаций и других статистик. Этот метод обладает целым рядом прекрасных свойств:

• достигает отличных показателей по точности решений;
• его чрезвычайно просто запомнить и реализовать;
• это однопроходный онлайн-алгоритм, что крайне полезно в некоторых ситуациях.

Оригинальная статья Уэлфорда была опубликована в 1962 году. Тем не менее, нельзя сказать, что алгоритм сколь-нибудь широко известен в настоящее время. А уж найти математическое доказательство его корректности или экспериментальные сравнения с другими методами и вовсе нетривиально.

Настоящая статья пытается заполнить эти пробелы.

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

Стоит ли изучать нейросети не специалистам в области машинного обучения? Каждый для себя ответит на этот вопрос сам. Мы же посмотрим на ситуацию с другой стороны — что делать разработчикам (и всем остальным), которые хотят больше знать про методы распознавания образов, дискриминантный анализ, методы кластеризации и другие занимательные вещи, но не хотят расходовать на эту задачу лишние ресурсы.

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

1. Что такое качество в разработке ПО?
2. Во сколько нам обходится некачественное ПО?
3. Кто отвечает за качество?

Для меня поводом задаться этими вопросами стала встреча с компанией в которой 3 месяца в году всё подразделение разработки (около сотни человек), занято устранением ошибок и дефектов, а остальные 9 месяцев они пишут ошибки софт для Заказчиков.

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

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

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

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

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

Если есть время, и заказчик хочет чуть большего, то гуглят реализацию наиболее популярного алгоритма (коим является «расстояние Левенштейна») и вписывают его.

В данной статье, я опишу сильно доработанный алгоритм, основанный, правда, на расстояния Левенштейна, и приведу примеры кода на C# нечеткого поиска по названиям, например: кафе, ресторанов или неких сервисов… В общем всё, что можно перечислить и имеет от одного до нескольких слов в своем составе:

«Яндекс», «Mail», «ProjectArmata», «world of tanks», «world of warships», «world of warplanes» и т.д.

В последнее время имена GridGain и Apache Ignite нередко мелькают в интернетах. Однако, судя по комментариям (например, здесь), мало кто понимает, что же это за продукт и с чем его едят.

В этой статье я попытаюсь доступным языком объяснить, и на примерах кода показать, что умеет Apache Ignite.