В этом посте мы расскажем о планах развития Space на текущий год. Мы хотим быть уверены, что движемся в правильном направлении и что функциональность, над которой мы работаем, — именно то, что вам нужно. Официальный выпуск Space 2020 запланирован на 3–4 квартал этого года.

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

Что войдет в релиз Space 2020

Йо-хо-хо!

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

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

Первым делом, введем ограничения на время. Сейчас мы ограничим его, чтобы часы были в пределе 0-24, а минуты 0-60, иначе будет выдаваться ошибка компиляции.

Constraints

Constraints это аспект языка, который отвечает за валидность реализации концепта. В нашем случае нам нужно ограничить property hours и minutes, поэтому мы создаем Constraints аспект концепта Time.

Здесь мы видим 3 пункта, которые отвечают за структуру AST.

• can be child: получаем на вход данные об узле, родительском узле, дочернем и все, что только можно и решаем, может ли реализация концепта в данном контексте быть дочерней или нет
• can be parent: то же самое, что и с child, только проверка на возможность быть родительским узлом
• can be ancestor: все то же самое, что с parent, но более вложенно: в данном случае мы можем идти как угодно выше по AST, дословно — может ли узел быть предком

Введение

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

Зачем нам нужен язык Weather?

В комментариях к 1 посту было следующее высказывание

С этой точки зрения, DSL — это как фреймворк, только с более удобным интерфейсом. Ясное дело, под один проект фреймворк делать никто не будет, за исключением совсем уж монструозных случаев. А сделать его под конкретную предметную область — почему бы и нет?..

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

Синтаксис

Язык Weather, который мы хотим реализовать, должен выполнять следующую задачу: мы должны уметь лаконично выражать условия (погода сегодня, например) и следствия (погода завтра, послезавтра...).
В языке Weather мы будем делать наши прогнозы отталкиваясь от 1 фактора: от температуры на сегодняшний день(массив объектов время + погодные условия).

19 апреля мы впервые провели Open Day в Москве.


Наташа Числер, HR директор JetBrains и главный организатор мероприятия:

Живешь себе живешь, репу не чешешь, в ус не дуешь. И тут внезапно тебе нужно переезжать с обветшавшего iPhone 6 на новенький iPhone X. А поскольку вся твоя жизнь за минувшие семь лет хранится в фоточках и видосиках старого смартфона, терять это добро тебе очень не хочется. И вот ты бэкапишь свое хозяйство через iTunes на Mac, пытаешься переехать на новую «балалайку» и вдруг оказывается, что места для бэкапа нового телефона на жестком диске твоего компьютера уже нет. Ты начинаешь судорожно расчищать авгиевы конюшни дисковое пространство, но результата «нема». Причем удаление «левых файлов» и очистка корзины ни к чему не приводит. Вот такой триллер разыгрался недавно с вице-президентом Parallels Николаем Добровольским. Под катом детективная история про обнаружение им «черной дыры» в macOS High Sierra, поиски истины и счастливый конец, которому могли бы позавидовать главные герои кинофильма «Титаник».

Предыстория

Привет! Меня зовут Виталий Шароватов, я уже 16 лет работаю в IT. Сейчас я руковожу направлением фронтенд в Badoo. В него входят две команды, которые занимаются разработкой и поддержкой десктопной версии сайта badoo.com, мобильной версии m.badoo.com и многими другими проектами. Да, десктопную и мобильную версии у нас делают отдельные команды. :)

Два с половиной года назад я пришел в Badoo разработчиком, со временем вырос до тимлида, а потом, когда было решено перевозить команду Desktop Web в Лондон, стал руководителем направления.

Прошлой осенью на Codemotion Milan я делал доклад о росте из разработчика в тимлида (и писал на Хабр статью об этом) и о том, с какими неожиданными моментами мне пришлось столкнуться, а теперь расскажу, как при переходе из лида в руководителя направления я справился с подбором и «выращиванием» тимлида в одной из команд (Mobile Web).

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

Как и следовало ожидать, почти ничего особенного не нашлось, однако одно объявление меня заинтересовало. В нём были такие строки:

«Кого мы возьмем «не глядя» или уровень выполняемых задач:
Вы скачали любой open source проект, собираемый при помощи gcc (объем исходного кода более 10 мегабайт) и для самого большого файла cpp смогли построить AST дерево при помощи clang с –fsyntax-only;
Вы скачали любой open source проект, собираемый при помощи Visual C++ (объем исходного кода более 10 мегабайт) и для самого большого файла cpp смогли построить AST дерево при помощи clang с –fsyntax-only;
Вы смогли написать утилиту, которая выделит все места деклараций и использования локальных переменных, а также все функции, не определенные в данном файле».

Ну что же, подумал я, какое-никакое, а развлечение на вечер.

Меньше трех месяцев прошло с HolyJS 2016 Piter, шутка ли, даже лето еще не кончилось, а доклады с конференции уже лежат в открытом доступе. Под катом вы найдете 5 лучших докладов, куда вошли как хардкорные вещи о JS-компиляторах, так и «антихипстерский» soft talk о трудностях выбора инструмента JS-разработчиком.

Кроме того, появились трое новых докладчиков в программе HolyJS 2016 Moscow.

Привет, хабраюзер. Поскольку, судя по всему, мы уже живем в будущем, то недавно я плотно засел за изучение новых фич ES6, ES7 и новых идей, предлагаемых React и Redux. И написал для своих коллег статью, в которой изложил сублимацию этих своих изысканий. Статья неожиданно получилась довольно объемной, и я решил опубликовать её. Заранее извиняюсь за некоторую непоследовательность изложения и отсылки к проприетарному коду из наших проектов — но думаю, что это всё же может помочь некоторым из нас лучше понять то, куда движется мир JavaScript, и почему не стоит игнорировать происходящее в нём.

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

React мы в Voximplant любим и ценим. Вовсе не из-за хайпа (полторы тысячи твитов о новом SDK просто потому, что это React Native) а потому, что фреймворк действительно удобный. Простое дробление интерфейса на маленькие изолированные кусочки – это то, чего так не хватало и Jade/Pug, и Web Components, и даже Angular.

Под катом адаптированный перевод статьи, в которой разработчики JetRuby Agency делятся впечатлениями о React: что использовали, что не использовали и что еще только планируют использовать.

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

Шаблоны проектирования — это допускающие многократное использование оптимизированные решения проблем программирования, с которыми мы сталкиваемся каждый день. Шаблон проектирования — это не класс или библиотека, которые мы можем просто вставить в нашу систему. Он — много больше. Это — некоторый шаблон, который должен быть реализован в надлежащей ситуации. Он не зависит от языка. Хороший шаблон проектирования должен быть таким, чтобы его можно было использовать с большинством языков (если не со всеми) в зависимости от характеристик языка. Чрезвычайно важно то, что любой шаблон проектирования необходимо использовать очень осторожно — если он применён в ненадлежащем месте, то его действие может быть разрушительным и породить много проблем для вас. Однако применённый в нужном месте в нужное время он может стать вашим спасителем.

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



Конечно, это был не совсем я, но близко. Дело в том, что давным-давно мне предложили помочь Вымпелкому с блогом. На немного необычных условиях. Первым стало отсутствие всякой официальщины – отсюда и совершенно отрывные посты (за часть из которых в корпоративном сегменте смело оторвали бы руки и не только), и самые актуальные темы (Базовая станция вредная? Ещё как!), и вообще много всего.

Но начну с самого начала. Итак, Хабр тогда был торт — большой и зверски агрессивный, хабов не было, а корпоративные блоги были чем-то вроде раздела «тупиковый отстой». За любую ссылку или рекламу тогда почти банили. Или забивали до -50 за час, например. С корпоративным рылом в такой калашный ряд было никак нельзя.

И ещё – Билайн, как и любой сотовый оператор, имел тысячи людей, не очень довольных его существованием. Поэтому первый пункт стратегии был довольно необычным, и мало кто мог позволить себе его повторить. Всё просто: пишут исключительно технари, а маркетинг на пушечный выстрел не подходит к постам.

Технари, кстати, оказались совершенно офигенные. Только плевать они хотели на Хабр, по большому счёту. Как и везде.

Мысли Криса Койера

Одна из мыслей, которая поселилась в моей голове: должен ли frontend-разработчик быть в курсе всего? В общем смысле, frontend-разработчик может использоваться и на других рабочих местах. Вся команда разработчиков заканчивает разговор на frontend-разработчике. В этом смысл моей идеи. Frontend-разработчики создают те вещи, с которыми будут взаимодействовать люди. Все этапы разработки проходят вместе с frontend-разработчиком. Возможно, именно поэтому это такая забавная работа! Поскольку frontend-разработчик занимает центральное место в цепочке разработки, и при этом мы имеем дело с большим количеством разных специалистов, мы должны понимать их работу и иногда подсказывать, что и как сделать лучше.

От переводчика

Всем привет, с вами Максим Иванов, и сегодня мы поговорим на довольно острую тему в сфере веб-разработки. Как утверждает Крис Койер, frontend-разработчик должен разбираться в очень многих вещах, о которых не все даже и задумываются. Конечно, мы должны понимать, что frontend-разработчик не главный в процессе разработки любого онлайн-сервиса или ПО в целом. На ту же позицию frontend-разработчика вы найдете больше откликов на вакансию, чем на позицию backend-разработчиком. Но почему же тогда Крис Койер считает, что работать frontend-разработчиком сложнее, ибо ты должен специализироваться во всем. Конечно, ситуаций в жизни очень много, разные компании по-разному используют своих специалистов, но в чем наверняка должен разбираться frontend-разработчик? Об этом мы сегодня и поговорим. Жду комментариев на эту тему, а сейчас приступим.

О программе Sketch я узнал еще год назад. Скачал демо тогда еще 2-й версии. Признаться, она меня совершенно не впечатлила. Какой-то слишком простой показалась. Я привык к навороченным интерфейсам софта от Adobe, а расположение панелей в стиле Apple iWork (Pages, Numbers, Keynote) мне по какой-то причине не нравится. К тому же мне оказалось комфортнее работать с темным интерфейсом, каковой нынче есть в Photoshop CC. Плюс Sketch 2 был достаточно кривоватый, содержал немало досадных багов, да и вообще впечатления не оказывал скоростью работы. В общем, поигрался с демкой и благополучно забыл. Впрочем, оказалось, что зря…

12 мая мы с товарищами зашли в московское метро с его открытием утром и, не выбираясь наверх, посетили все 199 доступных в данный момент станций до закрытия метрополитена. Зачем мы всё это сделали – совершенно не ясно, но я попробую рассказать, как так получилось.

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

По мере изучения вопроса я обнаружил, что идея сама по себе не то чтобы очень нова – в нью-йоркской подземке аналогичные соревнования проходят с 1966 года. Что же касается московского метро, то ЖЖ-пользователь estrella-de-sur полгода назад проехал его за 12 часов 36 минут (расчётное время – 11 часов 50 минут) по правилу «один шаг на каждую станцию». Но у нас была другая задача – мы хотели выйти на каждой станции и по возможности красиво её сфотографировать. Это означало, что нам в большинстве случаев придётся ждать на ней следующего поезда. Исходя из этого я и строил расчёт.

Предупреждение: если вы умеете решать задачу коммивояжёра на 200 узлах (с помощью генетических алгоритмов или без них) – вас, скорее всего, ждут в другом месте. Можете просто пролистать пост и посмотреть картинки.

Плохие отзывы в прессе о Node.js часто относятся к проблемам с производительностью. Это не значит, что с Node.js больше проблем, чем с другими технологиями. Просто пользователь должен иметь в виду некоторые особенности её работы. Хотя у технологии пологая кривая обучения, обеспечивающие её работу механизмы довольно сложные. Необходимо понять их, чтобы предотвратить появление ошибок производительности. И если что-то пойдет не так, необходимо знать, как быстро привести всё в порядок. В этой статье Даниэль Хан рассказывает о том, как Node.js управляет памятью и как отследить связанные с памятью проблемы.

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

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

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

Сегодня ко мне обратилась знакомая с просьбой помочь купить б/у Macbook Pro. Я сразу предупредил, что квалификация у меня близка к нулю, но чем могу — помогу. С PC плотно не работаю уже много лет, а Mac владею на верхне-чайниковом уровне. Беглый поиск по фразе «как проверить macbook pro» сразу же привел к исчерпывающей публикации rule на заданную тему: «Осторожно при покупке MacBook. Высокотехнологический способ мошенничества в оффлайне» geektimes.ru/post/157969 Но неопытноcть меня все же подвела.

Объявление:


То есть в объявлении предлагается топовая модель MacBook Pro «Core i7» 2.9 13" Mid-2012 (MD102). Реально это оказался MacBook Pro «Core 2 Duo» 2.66 13" Mid-2010 (MC375) — 4 GB RAM, 500 GB HDD. Блок питания был новый.

4 декабрьских дня подряд, порядка 1300 человек на протяжении 60 часов из 30 городов читали «Войну и мир». Беспрецедентный мультимедийный проект от ВГТРК, в течении которого произведение Льва Толстого было прочитано от первой и до последней строчки. Проект захватывает своей грандиозностью и тянет на книгу рекордов Гиннесса.

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

Под катом отрывки из романа, немного кода и мои мысли по процессу инфографирования данных на примере событийного таймлайна.

Наконец-то удалось организовать монтаж и тестирование опытных образцов устройства новой версии. Устройства, выполняющего лишь одну функцию, – уничтожение компьютеров. Впрочем, не будем ограничиваться только компьютерами, устройство способно вывести из строя практически любую технику оборудованную USB Host интерфейсом. К примеру, у меня на столе стоит осциллограф с USB интерфейсом (но он ещё пригодится), практически все смартфоны поддерживают USB OTG режим, TV, роутеры, модемы и т.д.