• Австралийские ученые создали Shazam для змей и пауков: приложение машинным зрением определяет вид животного
    0

    Больше похоже на Brachycerus muricatus. Тема на реддите https://www.reddit.com/r/whatsthisbug/comments/i70qsa/whats_this_south_african_arthropod_the_picture/

  • MVI и SwiftUI – одно состояние
    0

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


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


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


    Извините что немного не по теме статьи написал, затриггерило :)

  • Лучшие практики, эмпирический опыт и математика
    +1

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

  • Лучшие практики, эмпирический опыт и математика
    +1

    В статье как раз все идёт к простоте. Но я разделяю вашу точку зрения — «намерение»(intent) в моей команде главенствующий принцип ревью. То есть, код должен реализовывать явное и непротиворечивое намерение, и это намерение должно быть читаемо из кода. Однако, мне кажется, что хоть это сродни простоте, но это все же про лёгкость: simple vs easy.

  • Проблема стиля работы руководителя проекта или что делать с ответственной безответственностью?
    0

    Вы слышали про skip level one to one? Или про OKR? Если слышали, то вот вам и ответ.


    Я одно не пойму, как так получается у вас, что можно делегировать ответственность? Ответственность имеет направленность только вверх — ты можешь принять ответственность за нижестоящих, но не можешь делегировать.


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



    Ответственность здесь значит accountability, не responsibility. Responsibility как раз нужно делегировать. Не знаю как лучше перевести это два слова, извините.

  • Китайский мозг, или в защиту Яровой
    0

    С чего это вдруг мощность или тип сознания отличаются? Если сознание это про динамику и к-во элементов, то не имеет значение из чего сделан нейрон. Я не вижу как сознание сделанное из меньшего к-ва элементов может оказаться «мощнее». И, кстати, умение ходить после рождения не коррелирует с сознанием.

  • Китайский мозг, или в защиту Яровой
    +1

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


    В ваших измышлениях, правда, отсутсвует ещё один кусок пазла: скорость протекания реакций. С ростом масштаба (читай размер) системы меняется скорость взаимодействия и, соответсвенно, скорость протекания «мысли» у целого.


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


    PS. Если что, есть альтернативна гипотезе о сознании как свойство динамических систем. Я сейчас про современный панпсихизм, в котором тоже все очень интересно.

  • Еще потасовать или хватит?
    0

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

  • Еще потасовать или хватит?
    0

    Riffle конечно же, автокоррекция подвела. Оценка количества итераций которую вы привели это почти она. Bayer ее уточнил по тому как люди тасуют карты и оценка чуть-чуть понизилась до тех самых 7.

  • Еще потасовать или хватит?
    +18

    Эта статья могла бы быть просто великолепна если бы вы использовали математику из этой публикации https://arxiv.org/pdf/math/0501401.pdf. Jonasson в ней доказал что чтобы хорошо перетасовать колоду способом из статьи нужно минимум N^2 log N (для колоды из N карт) повторений, что чуть-чуть далеко от 64.


    Кстати, эта же работа ссылается на другую работу в которой был найден самый эффективный способ тасовки — 7 итераций river shuffle.

  • Я мотоцикл покупал, чтобы ездить, а не чтобы падать
    0

    Кстати да, есть разница в отношении к типу байка. Субъективно, кажется что к адвенчюрам самое нейтрально-уважительное отношение среди байкеров и автомобилистов. Особенно если это какой-нибудь GS обвешанный со всех сторон.

  • Я мотоцикл покупал, чтобы ездить, а не чтобы падать
    +1

    Как вам уже сказали — это миф. Громкий выхлоп на самом деле может стать причиной аварии.


    Буквально в этом сезоне наблюдал как на трассе джиксер с примерно +50-70 перепугал водителя в соседней полосе (тот испугался от резкого падения частоты звука и тупо дернул рулем, хорошо в другую сторону). Эффект Доплера превращают аргументы за громкий выхлоп в аргументы против. А на низкой скорости громкий выхлоп только раздражает всех, включая самого байкера.

  • Я мотоцикл покупал, чтобы ездить, а не чтобы падать
    0
    Вода скользкая. Листва очень скользкая. Рассыпанный гравий — капец. Резиновая прокладка на трамвайных путях — вообще за гранью добра и зла. Мотоцикл очень хорошо заносит, особенно в повороте.

    Дополню про плохой контакт с дорогой. Еще опасны середины полос всяким ГСМ, мокрая дорожная разметка, металлические люки, брусчатки, лужи и мокрый асфальт особенно в первые минут 20, пока все ГСМ с дороги водой смывает. И все то же самое сухое, но в холод.


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

  • А как на самом деле? Мифы и заблуждения о программистах
    0

    В моём комментарии только моя попытка анализа — моего взгляда на ситуацию там нет. Так откуда вы решили что я считаю что-то проблемой?

  • А как на самом деле? Мифы и заблуждения о программистах
    +1

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


    Из лично моего опыта: с равными возможностями и правами все лучше и лучше. Молодые девушки могут выбирать профессию и на собеседованиях к ним относятся нейтральнее или положительно (позитивная дискриминация). Да вы и сами привели в пример OSS.


    А вот вторая проблема более сложна. Предполагается что гендерные стереотипы в обществе давят/давили на молодых девушек и поэтому они не выбирают/выбрали программирование. Как с этим бороться, как менять общественное мнение? Кажется что, придумался только один вариант: менять мнение молодых девушек через положительную дискриминацию, таким образом балансируя стереотипы в обществе. Больше девушек на конференциях, больше девушек на рабочих местах, в общем, больше success stories.


    Насколько это хорошо я понятия не имею, через лет 10 будет видно.

  • А как на самом деле? Мифы и заблуждения о программистах
    +3

    Удивительно: а почему вы 10 лет продолжаете так жить (предполагаю что зарплата у вас выросла к 80)? Не интересовались своими опциями на глобальном рынке? Если дело в переезде, то на удаленке тимлид с 10 летным опытом наверняка сможет $100к.

  • Физик рассчитал, что жизнь всё-таки возможна в 2D-вселенной
    +3

    В статье имеется в виду сильный антропный принцип, вы же говорите про слабый антропный принцип.

  • TestMace — мощная IDE для работы с API
    0

    Есть очень продвинутый https://paw.cloud, нативный на macOS.

  • Быть фулстеком и не быть им
    +1

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


    По самой статье, кажется мне что весь разговор ни о чем. Я имею в виду спор fullstack, singlestack, stack-agnostic и тп. Все эти названия и попытки прикрепить специализации нам (программистам) вроде вообще не нужны. Но они точно нужны работодателям/рекрутерам для экономии. Но поскольку есть спрос, то появляется и предложение — цикл с обратной связью, где программисты начинают развиваться вглубь технологий, поощряя все эти специализации.


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

  • Магия SwiftUI или о Function builders
    0

    Очень близкий механизм использует typescript для поддержки tsx синтаксиса. Только там кроме билдеров нужно еще и информацию о типах нод объявлять для автокомплита внутри tsx контекста. Странно что этот proposal нигде не упоминает ее. Обычно в swift evaluation везде указывают существующие решения в других языках/платформах.


    На мой вкус реализация в typescript чуть функциональнее для пользователя API. Если кому интересно, то я писал о ней на хабре.

  • Интервью с Виталием Брагилевским: «Мир, в котором все будут программировать на Haskell — это вряд ли хороший мир»
    +4
    Потому что Haskell требует работы на очень высоком абстрактном уровне.

    Для повседневных задач этот самый уровень абстракции не такой уж и высокий — почти тот же уровень что дженерики. Так что аргумент именно с абстракцией кажется недостаточным.


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

  • Если есть в кармане пачка сигарет…
    0

    Раз в этом треде много курильщиков, может у кого есть релевантный опыт.


    Курю с 19 и когда курил сигареты, то спокойно мог не курить неделями потому что сами сигареты противны на вкус и запах. Даже самое лучшее что тогда было доступно (ричмонд произведённый на донском табаке) было противным.


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

  • Мифы современной популярной физики
    0

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


  • Как моя жизнь превратилась в книгу Кафки
    +6

    В этой истории очень многое странно.


    • Странно что в такой большой организации нет понятия корпоративной культуры и, соответственно, проверка ее соответствию на первых этапах собеседований. Корпоративная культура как раз с формой и качеством общения хорошо борется;
    • Непонятно как это может "в команде появиться новый сотрудник" без одобрения команды. У команды и ее тимлида последнее слово по найму пиров;
    • Какое отношение к этой истории имеет зарплата этого нового сотрудника? Если он смог договорится на лучшие условия — честь ему и хвала. Я долгое время работал в команде c лидом, который получал в 2.5 раза меньше меня (я договорился лучше чем он) и это никак не влияло на нашу работу;
    • Непонятно сколько сеньор-разработчиков в команде, из статьи следует что больше одного, но это просто невозможно. Если есть достаточно опыта чтобы считаться сеньором, то этот же опыт включает умение нейтрализации таких коллег как Джанни. Это чуть ли ни азы командной работы;
    • Тимлид тупо не сделал своей работы. Еще страннее что он не был отстранен от своей должности после расследования;
    • То же самое к менеджеру тимлида;
    • И к HR, пропустившей сообщение о проблеме;
    • Если возможно "На меня посыпались саркатические шутки о моих формулировках на английском, а медиатор над ними мило поржал" на митинге с медиатором, то тут два варианта — уходить из компании потому что она прогнившая насквозь или, если веришь в продукт и людей, идти по очереди по всей цепочке менеджеров по разработке и по HR;
    • Смена команды для внутри компании худшее что может быть в такой ситуации, если есть план поработать в этой компании какое-то продолжительное время — по факту это сдача своей команды. Это как если бы антитела уходили в незараженную часть тела чтоб не встречаться с вирусом. Если антитела эти умрут раньше чем вирус дойдет до их новой части тела, то для них все ок, а если нет, то вирус их и там догонит и бежать уже некуда. Телу (компания в этой метафоре) хуже всего, конечно;
    • Тут было много чего еще, но оно все в итоге сводится к тимлиду и его менеджеру, а они, как мы выяснили уже, не делали своей работы;

    Перечитал. Я бы ушел из компании с такими серьезными проблемами.

  • Работа с часовыми поясами в JavaScript
    0
    Значение -540 означает, что часовой пояс на 540 минут опережает целевой. Обратите внимание на минус, хотя смещение Сеула содержит плюс (+09:00). Не знаю, почему, но отображается именно так.

    Там минус потому что это значение разницы между локальным временем и UTC.


    Ещё одна особенность в том, что этот метод не про информацию о часовом поясе в объекте на котором он вызывается, а про локальную для системы. И это метод не статичный потому что он возвращает разницу на основе информации про день, месяц и год на объекте даты на котором вызван (чувствуется нехватка разных объектов Date, Time и DateTime в JS).


    По факту, с помощью этого метода можно узнавать историческую и текущую информацию о разнице между часовым поясом в хосте и UTC.

  • Почему строить базу знаний компании на основе mediawiki — недурная затея
    0

    На TypeScript и nodejs. Я тогда создал удобный модульный фреймворк для написания этого бота (да и кучи других ботов для внутренних нужд компании). Его можно посмотреть у меня в гитхабе https://github.com/dempfi/xene. Для распознавания вопросов и поиска ответа использовал https://js.tensorflow.org.


    В проекте есть мой заброшенный PR в котором можно подсмотреть простую распозновалку с нейронкой — хотел добавить в стандартную поставку фреймворка.


    Только предупреждаю: я фреймворк давно не обновлял. Парни из моей команды его форкнули и продолжают поддерживать но уже внутри компании. Не в OSS из-за чисто юридической подоплёки — форк поддерживают в рабочее время, а все что пишется в рабочее время принадлежит компании.

  • Почему строить базу знаний компании на основе mediawiki — недурная затея
    +1

    В одной прошлой компании где я работал я решал эту же проблему. Компания была удалённая и большая — вся коммуникация в slack. Решение само напросилось: каждый раз когда кто-то задавал вопрос в чатах, бот находимо подходящий ответ в базе знаний и постил в чат. Если информации не было, и кто-то давал ответ в чате, то одной командой можно было добавить пару вопрос/ответ в базу для следующих поисков.


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

  • Прямая линия с TM. v5.0. Важный опрос внутри
    +4

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

  • Почему строить базу знаний компании на основе mediawiki — недурная затея
    0

    ТС, обратите внимание на notion — там из коробки есть почти все что вы описали + лучше права доступа и куча классных функций именно для командной работы. Ну и вообще инструмент создавался для решения этой самой проблемы обмена знаниями (включая типизированные) в коллективе и отлично ее решает.


    Единственное чего ещё нет — API для расширений.

  • Хрупкий кабель дисплея MacBook Pro: очередная ловушка, в которую загнали себя инженеры Apple
    +13

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


    • ОС даёт мне доступ к хорошему коммерческому (OmniFocus, Sketch, Adobe Illustrator, Microsoft Office, Haskell Dev Platform, LittleSnitch, Alfred etc) и бесплатному (Idea, VSCode, iTerm, IINA, Transmission etc) софту, включая специфичный софт (FontLab, Glyphs, Lego DD, MotionPro, Xcode). Все что мне нужно для работы и хобби;
    • Нормальная консоль;
    • Очень хорошое коммьюнити, выпустившое такие чудесные штуковины как IINA, iTerm, brew;
    • Хорошая интерграция с телефоном. Я понятия не имею как я жил раньше без возможности скопировать на смартфоне и вставить на компе и наоборот;
    • TimeMachine;
    • Тут было ещё, что можно суммировать в «остальная ОС более-менее сносно работает»;

    Я рассматривал переход на Ubuntu/Elementary (внутренний параноик требовал) и это оказалось невозможным — аналоги программ хуже по качеству/функционалу, какой-то софт вообще нечем заменить. То же самое с виндой.

  • Фабрика GoPro переезжает, чтобы защититься от угрозы повышения импортных пошлин
    0

    Я бы посмотрел на компанию, которая первой построит завод на морской платформе в международных водах. Вообще тема производственных и научных центров свободных от предубеждений (ГМО, исследования со стволовыми клетками, клонирование и куча других) в международных водах звучит интересно.

  • Секретные хаки VS Code
    0

    Понял вас. Вообще есть шанс что сами разработчики vscode обновят правила в ходе плановой синхронизации с атомом.

  • Дилетант в opensource — lessons learned за 3 года
    +6

    Отличная статья, спасибо что написали.


    Дополню пару моментов.


    • Бесплатными путями (reddit, hacker news и прочие) можно сделать рекламу и это не требует особых скиллов маркетинга;
    • OSS — это отличный способ учиться с пользой. Я, например, не могу делать одни и те же hello world’ы на новой технологии и предпочитаю портировать полезную OSS библиотеку (включая ее релиз в репозиторий пакетов). Сразу получаю реальный, близкий к проду, опыт с новым языком и платформой и при этом помогаю чуть-чуть сделать технологию лучше;
    • OSS — это самый доступный способ для разработчика оказаться один на один со своими клиентами и заиметь опыт в полном цикле разработки продукта включая тот же маркетинг, ведение продукта, общение с клиентами и стратегическое планирование. Невероятно недооценённый и полезный аспект;
    • Некоторые компании используют поддержку OSS начинаний своих разработчиков в первую очередь для комфорта этих самых разработчиков. Счастливый разработчик — продуктивный разработчик. Из моего опыта, все компании где поддерживали OSS входили именно в эту категорию;
    • Больше двух более-менее популярных проектов одному потянуть сложно. Более-менее популярный — это сотни звёзд на гитхабе. Поэтому хорошо бы как можно раньше находить людей в коммьюнити (если они сами не проявились к этому моменту) кому можно делегировать хотя бы разгребание Issues.

    Есть ещё огромное количество вещей связанных не с ведением своего проекта, а с помощью другим проектам, но статься не о том.

  • Секретные хаки VS Code
    0

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

  • Секретные хаки VS Code
    0

    То что у вас на скриншоте — это проблема встроенной подсветки синтаксиса для C в vscode с одной стороны и отсутствия поддержки в темах с другой. Поскольку правила для синтаксиса С в vscode напрямую взяты из того самого atom'а, то можно легко их обновить.


    1. Открываете ПР с обновлением встроенных правил для C на самую последнюю версию из atom'а;
    2. Открываете Issue для темы в которой вы хотели бы увидеть поддержку;
    3. Ждете релизов...
    4. Profit.

    Если сделаете первую часть — я с радостью добавлю поддержку в мою ayu.

  • Безликий код убьет программирование, и ничего мы с этим не сделаем
    0

    ТС, если хочешь и денег и творчества — иди в ресёрч отдел какой-нибудь большой компании. Там тебе и денег много дадут и твори сколько влезет интересные вещи.


    Вот тебе совет. Найди контакт (вот тебе твиттер @lorentzframe) Браяна Бэкмана (он очень дружелюбный и открытой человек) из бывшего Microsoft Research и текущего Amazon Robotics; спроси у него как попасть в этот самый Microsoft Research; набери скиллов которых ещё нет и стучись к ним. Дерзай, в общем!

  • Так ли страшен Rust, как его малюют
    +1

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


    Определенно есть положительная корреляция. Любая новая фича требует как минимум места в голое для запоминания. А если у неё еще и свой синтасксис, то тем более.

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


    И, если нигде не сделал логических ошибок, самые выразительные языки имеют минимум синтаксиса и правил, по факту оперируя несколькими довольно простыми концепциями (Haskell какой-нибудь или Clean).

  • Так ли страшен Rust, как его малюют
    +2
    Чем сложнее язык, тем богаче фразы, составленные с его помощью, и тем лучше он может выразить требуемую предметную область.

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

  • Metro 4 — путь длиною в 6 лет. Краткая история Metro UI CSS
    0

    Я имел в виду через обычный CSS class (например для чекбоксов), но идею я понял — спасибо.

  • Metro 4 — путь длиною в 6 лет. Краткая история Metro UI CSS
    0

    Недавно наткнулся на ваш проект и в целом он понравился. Один только вопрос крутился у меня в голове пока смотрел на компоненты — зачем стилизация компонентов сделана через data-style а не через классы?