Pull to refresh
55
0
Евгений Успенский @BuranLcme

Frontend Team Lead

Send message

Все сервисы Yandex Cloud (включая Wiki и Tracker) для пользовательского контента используют Yandex Flavored Markdown, который используется в Diplodoc, и совместно его развивают.

Для пользователя это означает, в первую очередь, единый UX всех сервисов. Во-вторых, легкость перехода. Например, команда может по каким-то причинам сначала вести документацию в Wiki (для быстроты, потому что пока это не документация, а записки для себя и т.п.), а потом легко экспортировать её в Diplodoc при выходе в production.

Бонусом, знаю людей, которые пишут документацию в WIki WYSIWYG-ом, а потом экспортируют в Diplodoc. Но это, конечно, костыль. Думаю, в будущем визивиг в каком-то виде подружится с Diplodoc, тем более что он тоже в open source.

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

После покупки куска Parallels (под брендом Odin), занимавшегося автоматизацией продажи облачных сервисов (Parallels Automation), крупнейший дистрибьютор и облачных сервисов тоже. Каждая пятая подписка на O365 в мире сейчас идет через Ingram. Опять же, через множество реселлеров, поэтому покупая офис вы можете даже не знать, что на самом деле это Ingram.
Если ваш вопрос на самом деле звучит «что Ingram делает в России?», то все RnD осталось тут, выросло и переехало в новый офис. Основные задачи: развитие Parallels/Odin Automation и разработка Ingram-специфичных вещей.

Кстати, в посте похоже ошибка. Эти 300 миллионов, скорее всего, не инвестиции в Parallels, а покупка Odin-a. И сейчас речь идет о покупке именно Parallels, который занимается приложениями для айфона и мака. Виртуоза и плеск одновременно с Odin-ом были выделены в отдельные компании и будут проданы по отдельности. Или уже проданы)
Заказывали перевод? Ловите!)
Я с той же целью упражнялся с wtfjs. И предпочитал смотреть не в MDN, а напрямую в спецификацию
Российское RnD-подразделение американской корпорации. Периодически бывают бизнес игры для руководителей. Последняя была аккурат вчера. Задания не такие идиотские, просто попытки имитировать стрессовую ситуацию: ограниченное время, ресурсы, сложные правила и т.д. Цели заявлены такие же — прокачка навыков коммуникации/лидерства/т.п. в команде. Результат примерно такой же, только без переломов)
Это уже от человека зависит. Я в переписке договаривался о месте встречи и потом общался уже в живую.
Есть идеи сделать какую-то аппликуху, где можно видеть участников, что им интересно и, например, написать им в личку

на РИТ++ в этом году был прекрасный телеграм-бот, который делал примерно это. Спрашивал несколько вопросов про что интересно и чем можешь быть полезен, а потом рекомендовал других участников для нетворкинга. Можно было пропустить или начать переписку.
Киллер-фича графа — отсутствие необходимости версионировать апи. Из чего вытекает простота использования и поддержки точки взаимодействия клиента и приложения.

А почему вы считаете, что у других языков запросов есть потребность в версионировании?
Сколько ни читаю посты об GraphQL, не могу понять чем он принципиально лучше существующих уже давным давно URI-совместимых query language-ей. Например, RQL или odata. Они прекрасно решают проблему выбора необходимых полей, поддерживают фильтрацию, паджинацию и все остальное. В отличии от GraphQL они не противопоставляют себя REST-у, а отлично его дополняют. Таким образом, сравнивать GraphQL нужно не с голым REST, а с существующими языками запросов.
Система типов для описания данных, в свою очередь, очень похожа на также давно существующую JSON Schema.
Видимо европейская специфика. Наш офис работает 24/7. Компании по деньгам ничего не стоит, а от трудоголиков и сов больше пользы можно получить.
Понятно что в строку можно записать почти что угодно. Минификатор в том числе этим и занимается. Но, судя по большинству примеров, запросы GraphQL это все-таки структуры и их лучше писать в отформатированном виде.
RQL это просто запросы к хранилищу. Никакого байндинга не подразумевается.
В APS UI отслеживание можно делать на уровне хранилищ. Повесить observer на хранилище и по его событиям обновлять виджеты, которые отображают данные из него.
Наш проект старше чем graphql, а сам по себе RQL еще старше.
Плюс для нас удобно, что RQL запрос это просто строка. Например, в APS приложении структура экранов описывается XML-метафайлом и приложение может указать какие данные нужны для отображения этого View. Тогда в момент показа они уже будут загружены, а если обязательных данных нет, то View будет скрыто из меню и пользователь не сможет на него перейти. В виде строчного query это удобно описать, а в graphql формате, похоже, это будет выглядит весьма громоздко.
Посмотрел документацию по JSONPath. Не увидел там возможность поддержки функций типа like и логических операторов.
Спасибо большо! Поправим. Конечно, жаль, что Habr не позволяет просто указать ширину колонок.
Простите, а кто тут неизвестный? Алиса в стране чудес? Автостопом по галактике? Оливер Твист?
С русской классикой тоже было бы интересно, но это уже не перевод, а «наш ответ Чемберлену». Кстати, хорошая мысль для поста на Хабр.
Новых книг не знаю, по-моему, их вообще нет. Но у парней неплохая дока. Есть туториалы вполне в стиле книги. Есть персонально для многих модулей отдельные статьи. И есть автогенеренный словарь API. Относительно блогов, David Walsh раньше писал про Dojo, но уже давно ничего нового не видно.
В dojo/dojo кроме работы с DOM-ом еще много всего интересного: Promises, AMD загрузчик, работа с источниками данных, утилиты для работы с массивами, числами, временем и пр.
Видимо с годами что-то изменилось, но большая часть моих коллег и друзей ПриМаты — в дипломе у них написано «прикладная математика и информатика». Факультеты и кафедры вполне программистские закончены.
В рамках личных наблюдений в роли соискателя, рекрутеры предпочитают пользоваться HH, LinkedIn, джоб.ру и профильными сайтами. При прочих равных, на 19 приглашений с HH было 0 с моего круга.

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

Information

Rating
Does not participate
Location
Москва и Московская обл., Россия
Date of birth
Registered
Activity