Начал работу над сервисом https://answeropedia.org — это как Википедия, только с вопросами и ответами. Вы задаете вопрос и получаете один полный и исчерпывающий ответ.
Зачем это вообще надо, если есть нейросети? -- очевидный вопрос в 2025 году. Есть гипотеза, что на фоне засилья ИИ (и, зачастую, недостоверных ответов) спрос на "проверенные людьми" ответы со стороны пользователей будет только увеличиваться.
В ноябре 2022 года коллега завел разговор на тему "почему в Васи много бейджиков в профиле Гитхаба, а у Пети мало?".
Сам GitHub прямой ответ на этот вопрос (в официальной документации, в одном месте) не даёт, поэтому решил я тогда, на скорую руку, создать репозиторий https://github.com/gomzyakov/achievements, который, по-сути, является справочником значков и достижений на GitHub.
Стараюсь, по мере возможностей, поддерживать этот список достижений в актуальном состоянии. Надеюсь, кому-то да пригодится ;)
Около месяца назад мы с супругой начали играть в игру, где из колоды карточек вытаскиваешь одну, на карточке написано задание которое необходимо выполнить.
Однажды я вытянул карточку "напиши писмо в будущее, представь, что ты сегодняшний хочешь сказать себе или кому-то из близких через 10 лет".
Бумажное письмо я тогда написал, но сразу подумал о том, что было бы прикольно за пару вечеров сделать проект, с помощью которого можно оправить в будущее email. Так и родился сайт everletter.org
Да, уже существует довольно много подобных сайтов, но когда это кого-то останавливало? :) Есть конкуренты -- значит есть спрос.
Вряд ли можно назвать пет-проектом или, тем более, стартапом, но оставлю ссылку на страницу GutHub Badges & Achievements здесь. На странице, как можно догадаться из названия, приведён полный список значков и достижений на GitHub.
Встречал достаточно команд которые активно начинали визуализировать функционал, но, повыкладывав пару недель красочные стены своего кабинета в Инстаграм, завязывали с этим делом.
Мы как-то тоже попробовали, но, увы, не полетело.
Я не хочу сказать, что подход плох, просто есть достаточно много мелких, казалось бы, несущественных моментов, которые препятствуют оклеиваюнию рабочего пространства стикерами. Из не очевидных, вроде отсутствия подходящего помещения, на ум сразу приходят:
— На раннем этапе истории (желтые листки) часто дублируются. Причем какая-нибудь авторизация пользователя может, пусть и формально, присутствовать во всех задачах/действиях;
— Не всем нравится заниматься этим делом и, лично я считаю, что привлекать команду разработки стоит только на этапе историй, иначе планирование затянется и превратится в процесс обсуждения бизнес-целей с тестерами и фронтендерами;
— Очень слабый контроль за зависимостями задач (пользовательских историй) и, как следствие, практически полное «переобдумывание» некоторых постановок при переносе в онлайн;
— Иногда проще просто описать проект каскадным списком (условно приняв, что без отступа — это «идеи», отступ первого уровня — это «действия» и т.д.), чем расклеивать стикеры;
П.С. Ну и, конечно, плохой почерк участвующих в процессе — ой как мешает сосредоточиться, временами :)
Есть подозрение, что «кнопочное мышление» — это отголоски подхода «сверху вниз» (от дизайна к данным), проповедуемому в Getting Real от 37signals, и гибких методологий разработки.
Собственник или гендир, как человек действительно заинтересованный в глубоком анализе проблем и фундаментальном их решении, чаще всего на уровень конкретного проекта не погружается, а менеджеру гораздо проще поменять цвет кнопки и увеличить щрифток, показать положительные результаты на А/Б тестах начальству и получить премию.
Проблема, на мой взгляд, не в кнопочном мышлении, а в, зачастую, низкой заинтересованности принимающих решение лиц и нежелении погружаться в проблему/задачу.
Спасибо за статью, полагал, что переводится всё чуть ли не в блокноте.
Подготовленное к локализации iOS-приложений имеет несколько файлов Localizable.strings (для каждого языка) условно такого содержания:
/* Надпись на кнопке алерта, при нажатии на которую осуществляется открытие определенного URL-а в Safari */
"openUrlButtonTitle" = "Перейти на сайт";
/* Надпись на кнопке алерта, при нажатии на которую происходит отмена перехода на сайт */
"alertCancelButtonTitle" = "Отмена";
В используемой вами TM-программе MemoQ я не увидел, чтобы выводились какие-либо комментарии к переводимым строкам. Возникает вопрос: насколько вообще актуально писать развернутые комментарии? Если ли в этом смысл или при переводи их всё-равно никто читать не будет?
P.S. Насколько я понимаю, если необходим перевод на несколько десятков языков, то сначала всё переводится на английский, а потом уже с английского осуществляется перевод на суахили и клингонский. Как в этом случае передать специфику выражений, сохранить общую стилистику текста?
Предложенная вами методика, calendar-driven development, реализуема на практике далеко не всегда. У меня на работе, например, используется достаточно распространенная схема с ветками master-develop и форком основного репозитория. Задачи достаточно крупные, логически и функционально законченные, в большинстве случаев выходящие за рамки 2-3 дней.
Как бы мне не хотелось стимулировать себя закрашиванием квадратиков, если я начну отправлять мелкие PR-ы, то уже через полчаса будет «ай-йа-йа-й» от человека ответственного за кодревью — проверять достаточно больший, законченные по смыслу куски кода значительно проще.
Да, моя работа — не оупенсорс, но, во-первых, многие проекты с открытыми искодниками придерживаются подобной схемы разработки, а, во-вторых, большинство хабравчан, я полагаю, всё-таки занято на ниве разработки коммерческого ПО с очень похожими требованиями к PR.
Интуиция подсказывает, что задача не тривиальная, много подводных камней. Вообще, проблема с мерджем сториборда стоит действительно остро и подобный инструмент был бы многим полезен.
Совсем недавно GitHub обновил дизайн, сосредоточившись, как это сейчас принято, на контенте. В контексте гихаба (а им, я уверен, пользуются многие хабровчане), именование коммитов в прошедшем времени выглядит гораздо логичнее, чем в настоящем:
Найти работу в ИТ без высшего образования станет практически невозможным, так
как информационные технологии уйдут далеко вперед.
Исходя из личного опыта — возможности трудоустройства в IT-сфере практически не связанны с наличием высшего образования. Адекватные наниматели прекрасно понимают, что реальные навыки связанны, большей частью, с увлечённостью человека и его стремлением к самообразованию, а не с наличием диплома.
Каким образом наличие вышки страхует от чрезмерной скорости развития информационных технологий и вовсе непонятно. Современное высшее образование даже в хороших вузах, увы, зачастую не говорить вообще ни о чём.
Не знаю у кого как, но у меня накопители 5.25" и 3.5" прочно ассоциируются с дисководами для соответствующего размера дискет. В вашем случае корректней было бы подписать позиции как оптический привод и кард-ридер.
Кто-то ведь приложением «юрекуру кору» пользуется, стало быть не всегда оно опаздывает с предупреждениями, помогает кому-то…
Небольшой вопрос по бытовым японским телефонам — как осуществляется рассылка/прием уведомлений? Нечто вроде услуги «Хамелеон» от Билайна, но со звуком?
Мне кажется, если бы была реальная техническая возможность скинуть всем какое-нибудь сообщение без спроса, этой возможностью пользовалось бы не только правительство с целью оповещения о землетрясениях :)
Я правильно понимаю, что уведомление осуществляется по факту землетрясения?
В чём тогда его смысл? Разница в 10-30 секунд не должна оказывать никакого влияния на пользу сообщения — за это время просто выйти из дома не всегда возможно, не говоря уже о «эвакуации» в безопасное место.
Да и не важно сколько реальных людей будет пользоваться оповещениями о землетрясениях — Apple часто задаёт тон, после чего уже тысячи сторонних разработчиков создают свои приложения, полезные заведомо долее широкому кругу пользователей.
Ход мыслей до шестого шага, в общем-то, верный, однако стоит учитывать тот факт, что предлагаемые потребителю устройства будут отличаться от нынешних не только большим количеством камер, они будет совершеннее во многих других аспектах (другие технологии передачи данных, экраны с большим разрешением и т.п.). За совокупность таких вот улучшений и будет платить пользователь.
Седьмой шаг очень спорный. Предполагаемые вами сценарии использования весьма специфичны и, на мой взгляд, будут реализованы только в единичных устройствах, не затронув мэйнстримовые девайсы.
Начал работу над сервисом https://answeropedia.org — это как Википедия, только с вопросами и ответами. Вы задаете вопрос и получаете один полный и исчерпывающий ответ.
Зачем это вообще надо, если есть нейросети? -- очевидный вопрос в 2025 году. Есть гипотеза, что на фоне засилья ИИ (и, зачастую, недостоверных ответов) спрос на "проверенные людьми" ответы со стороны пользователей будет только увеличиваться.
Пока это лишь гипотеза, время покажет.
В ноябре 2022 года коллега завел разговор на тему "почему в Васи много бейджиков в профиле Гитхаба, а у Пети мало?".
Сам GitHub прямой ответ на этот вопрос (в официальной документации, в одном месте) не даёт, поэтому решил я тогда, на скорую руку, создать репозиторий https://github.com/gomzyakov/achievements, который, по-сути, является справочником значков и достижений на GitHub.
Стараюсь, по мере возможностей, поддерживать этот список достижений в актуальном состоянии. Надеюсь, кому-то да пригодится ;)
Около месяца назад мы с супругой начали играть в игру, где из колоды карточек вытаскиваешь одну, на карточке написано задание которое необходимо выполнить.
Однажды я вытянул карточку "напиши писмо в будущее, представь, что ты сегодняшний хочешь сказать себе или кому-то из близких через 10 лет".
Бумажное письмо я тогда написал, но сразу подумал о том, что было бы прикольно за пару вечеров сделать проект, с помощью которого можно оправить в будущее email. Так и родился сайт everletter.org
Да, уже существует довольно много подобных сайтов, но когда это кого-то останавливало? :) Есть конкуренты -- значит есть спрос.
Вряд ли можно назвать пет-проектом или, тем более, стартапом, но оставлю ссылку на страницу GutHub Badges & Achievements здесь. На странице, как можно догадаться из названия, приведён полный список значков и достижений на GitHub.
Список достижений (ачивок) поддерживается сообществом и, в настоящее время, переведен уже на более чем 10 языков. Репозиторий проекта https://github.com/badges-and-achievements/badges-and-achievements.github.io открыт для правок, а хостится всё это, естественно, на GitHub Pages.
Мы как-то тоже попробовали, но, увы, не полетело.
Я не хочу сказать, что подход плох, просто есть достаточно много мелких, казалось бы, несущественных моментов, которые препятствуют оклеиваюнию рабочего пространства стикерами. Из не очевидных, вроде отсутствия подходящего помещения, на ум сразу приходят:
— На раннем этапе истории (желтые листки) часто дублируются. Причем какая-нибудь авторизация пользователя может, пусть и формально, присутствовать во всех задачах/действиях;
— Не всем нравится заниматься этим делом и, лично я считаю, что привлекать команду разработки стоит только на этапе историй, иначе планирование затянется и превратится в процесс обсуждения бизнес-целей с тестерами и фронтендерами;
— Очень слабый контроль за зависимостями задач (пользовательских историй) и, как следствие, практически полное «переобдумывание» некоторых постановок при переносе в онлайн;
— Иногда проще просто описать проект каскадным списком (условно приняв, что без отступа — это «идеи», отступ первого уровня — это «действия» и т.д.), чем расклеивать стикеры;
П.С. Ну и, конечно, плохой почерк участвующих в процессе — ой как мешает сосредоточиться, временами :)
Собственник или гендир, как человек действительно заинтересованный в глубоком анализе проблем и фундаментальном их решении, чаще всего на уровень конкретного проекта не погружается, а менеджеру гораздо проще поменять цвет кнопки и увеличить щрифток, показать положительные результаты на А/Б тестах начальству и получить премию.
Проблема, на мой взгляд, не в кнопочном мышлении, а в, зачастую, низкой заинтересованности принимающих решение лиц и нежелении погружаться в проблему/задачу.
Подготовленное к локализации iOS-приложений имеет несколько файлов Localizable.strings (для каждого языка) условно такого содержания:
В используемой вами TM-программе MemoQ я не увидел, чтобы выводились какие-либо комментарии к переводимым строкам. Возникает вопрос: насколько вообще актуально писать развернутые комментарии? Если ли в этом смысл или при переводи их всё-равно никто читать не будет?
P.S. Насколько я понимаю, если необходим перевод на несколько десятков языков, то сначала всё переводится на английский, а потом уже с английского осуществляется перевод на суахили и клингонский. Как в этом случае передать специфику выражений, сохранить общую стилистику текста?
Как бы мне не хотелось стимулировать себя закрашиванием квадратиков, если я начну отправлять мелкие PR-ы, то уже через полчаса будет «ай-йа-йа-й» от человека ответственного за кодревью — проверять достаточно больший, законченные по смыслу куски кода значительно проще.
Да, моя работа — не оупенсорс, но, во-первых, многие проекты с открытыми искодниками придерживаются подобной схемы разработки, а, во-вторых, большинство хабравчан, я полагаю, всё-таки занято на ниве разработки коммерческого ПО с очень похожими требованиями к PR.
Исходя из личного опыта — возможности трудоустройства в IT-сфере практически не связанны с наличием высшего образования. Адекватные наниматели прекрасно понимают, что реальные навыки связанны, большей частью, с увлечённостью человека и его стремлением к самообразованию, а не с наличием диплома.
Каким образом наличие вышки страхует от чрезмерной скорости развития информационных технологий и вовсе непонятно. Современное высшее образование даже в хороших вузах, увы, зачастую не говорить вообще ни о чём.
Небольшой вопрос по бытовым японским телефонам — как осуществляется рассылка/прием уведомлений? Нечто вроде услуги «Хамелеон» от Билайна, но со звуком?
В чём тогда его смысл? Разница в 10-30 секунд не должна оказывать никакого влияния на пользу сообщения — за это время просто выйти из дома не всегда возможно, не говоря уже о «эвакуации» в безопасное место.
Да и не важно сколько реальных людей будет пользоваться оповещениями о землетрясениях — Apple часто задаёт тон, после чего уже тысячи сторонних разработчиков создают свои приложения, полезные заведомо долее широкому кругу пользователей.
Седьмой шаг очень спорный. Предполагаемые вами сценарии использования весьма специфичны и, на мой взгляд, будут реализованы только в единичных устройствах, не затронув мэйнстримовые девайсы.