Снобов и не умеющих общаться корректно по форме — за дверь, можно немножко отпинать. Там само наладится. Когда человек поймет, что коллеги его реально могут научить интересным трюкам, дать дельные советы, не унижая при этом, сам втянется.
и паралельно роль QA уже тестировать и не ждать от девелоперов «мы закончили»
Замечательная идея… я прямо вижу, как разработчики вносят сегодня изменения в ту часть, которая была протестирована QA вчера. В результате либо QA не отловит проблему, либо будет делать одну работу дважды.
Постановка может быть «нам надо сделать фичу X в продукте Y». Команда делает быстрый ресерч — какие изменения и в каком модуле должны быть сделаны, что протестировано, какие тесты написаны.
Круто, если у вас есть свободная команда под этот проект. У меня на работе, например, в моей команде, которая занимается back-endом, 4 человека, и у каждого своя зона ответственности. Собрать всех вместе, чтобы пилить одну фичу? Не в этой жизни, это тупо расходование ресурсов попусту, потому что 3/4 задач вообще неясны и их постановка непонятна 3/4 команды. И только 1/4 понятна всем.
по сути они склоняют всех к мультитаскингу — ибо сделал изменения — жди вопросов/предложений, а чтобы время не пропадало займись чем то еще, и так переключайся туда-сюда по кругу. Мультитаскинг надо избегать ибо он жрет эффективность и концентрацию.
Иногда это неизбежно — команда маленькая, ты не можешь ждать, пока освободится твой коллега, который сделает ревью, а освободится он завтра к вечеру.
2) зажимают все общение в рамки письменного изложения. Письменно прийти к решению/пониманию в разы сложнее/дольше чем вербально. Не все умеют излагать мысли на бумаге, не все умеют понимать абстрактные идеи изложенные письменно (кому то нужна картинка например или какая то жизненная аналогия).
Надо учиться. Это имеет огромный плюс — изменение описано формально так, что сможет понять твой коллега, который не в теме — это значит, что через год, когда ты, или кто-то еще будет работать над этим куском, можно будет открыть комментарии к коммиту и описание проблемы и ее решения в task'е — ticket'е и понять, чтож там было, и почему сделано именно так. Это по сути частичное документирование кода. В противном случае получится так: ты что-то исправил, закоммитил с коротким комментарием вида «исправлениа бага с пустым полем ID», потом объяснил на пальцах коллеге за соседним столом, который будет делать ревью, а через день-два ВСЕ забыли, что это было вообще, не говоря уж о деталях реализации или том, что сам баг вызывался путем манипуляций «два притопа, три прихлопа» и только в полную луну. А так — вот оно — открыл таск — все есть.
Eсли человек, к примеру, из раза в раз делает плохо, сказать ему «Как я уже говорил» или «Мы это уже обсуждали» — абсолютно нормально.
… а потом выяснится, что «плохо» — оно не плохо, а просто субъективный взгляд делавшего ревью. Который никто (по данному конкретному узкому вопросу) не принимает в расчет.
Было написано «Белоруссия», а не «Республика Б.», так что претензия — не в кассу. Все три названия — что Белоруссия, что Беларусь, что Республика Беларусь — используются повседневно.
Белору́ссия[9] (белор. Беларусь (инф.)), официальное название — Респу́блика Белару́сь (белор. Рэспубліка Беларусь (инф.)), официальное сокращённое название Белару́сь — государство в Восточной Европе.
Вы говорите про 78 минут на реализацию кеширования, в любом языке ориентированном на web на это уходит пару минут, если не секунд и все это занимает одну строчку. Так как есть библиотеки кеширования.
Так… это самое… я не видел, как автор реализовал свое кеширование, но если в виде отдельного встраиваемого модуля (если нет, то он ССЗБ), то у него теперь в любом другом проекте на асме тоже займет пару минут на реализацию, так как теперь есть библиотека.
Для меня SO — всего лишь один из сайтов выдачи в гугле, при поиске каких-либо данных. Получается, что я из «поколения 2000х». С другой стороны, есть разница — если мы разрабатываем что-то с нуля, то да — я полезу читать RFC и так далее. А если мне надо найти, почему Chrome при выдаче совершенно валидного пакета через WebSockets сходит с ума — путь только в гугл, потому что это уже найденная кем-то проблема.
Найденное чужое решение действительно не запоминается, но не в случае, когда ты сам потратил кучу услий на то, чтобы найти решение проблемы, и не преуспел. Важен сам процесс поиска.
Это без вопросов, символьные устройства — отдельная статья. Но определенная гибкость в плане работы с терминалом в пидипишке есть, пусть это и вызвано другими причинами.
1) В таком случае двоичный код x86 запушенный в эмуляторе — Bochs — это не скомпилированная программа, ведь она исполняется эмулятором.
Тут надо разделить эмулятор машины и интерпретатор языка. Что bochs, что JVM — эмуляторы машин, кмк.
2)железные JVM
Понимаете, использовать опкоды вместо ассемблера для написания веб-сайтов — это такая же затея как и использовать ассемблер вместо той же java или php.
Не совсем верная аналогия. Но о неразумности использования ассемблера я автору неоднократно говорил в предыдуших его темах. Еще раз, на всякий случай: не боритесь против ветряных мельниц, я не говорю, что писать сайты на асм вместо php или Java норма, напротив. Парой сообщений выше я уже написал вам, но вы проигнорировали:
Вы пытаетесь доказать, что писать на асме подобные приложения сложно по сравнению с ЯВУ. Это бесполезная борьба с ветряными мельницами. Говоря об удобстве, имеется в виду, что «все не так плохо, как казалось», не более. ИМХО.
А преимущество использования ЯВУ против ассемблера — кроссплатформенность, более удобные абстракции, большая встроенная библиотека, и многое другое.
Разумеется! С этим никто не спорит как бы.
Но вы утверждаете что на ассемблере писать — одно удовольствие.
Не-а. Автор статьи утверждает, что писать на современном макроассемблере fasm — намного приятнее и проще, чем «встарь». По крайней мере, я именно об этом веду разговор.
Так всё-таки — а почему ж тогда сразу не на опкодах? Если расчитывать адреса вручную — так можно вообще дико оптимизированный код писать. Прям каждый такт выжать. А то сейчас привыкли ленивые программисты медленный код писать, ассемблер всё за них делает…
Нет, я же говорю вам: использование современного fasm — это уже ближе к C, чем к традиционному ассемблеру. Такие вот проекты — это показывают. А опкоды и адреса вручную — это шаг в противоположную сторону.
Нет. Это яркий пример экономической блокады. За ЮК решали взрослые дяди. А так-то можно сравнить со свободным выбором Либерии, например.
В этой фразе — призыв использовать хорошо зарекомендовавший себя подход, а не призыв мессии.
Замечательная идея… я прямо вижу, как разработчики вносят сегодня изменения в ту часть, которая была протестирована QA вчера. В результате либо QA не отловит проблему, либо будет делать одну работу дважды.
Круто, если у вас есть свободная команда под этот проект. У меня на работе, например, в моей команде, которая занимается back-endом, 4 человека, и у каждого своя зона ответственности. Собрать всех вместе, чтобы пилить одну фичу? Не в этой жизни, это тупо расходование ресурсов попусту, потому что 3/4 задач вообще неясны и их постановка непонятна 3/4 команды. И только 1/4 понятна всем.
Иногда это неизбежно — команда маленькая, ты не можешь ждать, пока освободится твой коллега, который сделает ревью, а освободится он завтра к вечеру.
Надо учиться. Это имеет огромный плюс — изменение описано формально так, что сможет понять твой коллега, который не в теме — это значит, что через год, когда ты, или кто-то еще будет работать над этим куском, можно будет открыть комментарии к коммиту и описание проблемы и ее решения в task'е — ticket'е и понять, чтож там было, и почему сделано именно так. Это по сути частичное документирование кода. В противном случае получится так: ты что-то исправил, закоммитил с коротким комментарием вида «исправлениа бага с пустым полем ID», потом объяснил на пальцах коллеге за соседним столом, который будет делать ревью, а через день-два ВСЕ забыли, что это было вообще, не говоря уж о деталях реализации или том, что сам баг вызывался путем манипуляций «два притопа, три прихлопа» и только в полную луну. А так — вот оно — открыл таск — все есть.
… а потом выяснится, что «плохо» — оно не плохо, а просто субъективный взгляд делавшего ревью. Который никто (по данному конкретному узкому вопросу) не принимает в расчет.
По факту — технические специалисты низкой квалификации. Же.
«А ты видишь здесь финский флаг, Икея-сан?»(с).
https://ru.wikipedia.org/wiki/%D0%98%D0%BC%D0%B5%D0%BD%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D0%B5_%D0%B1%D0%B5%D0%BB%D0%BE%D1%80%D1%83%D1%81%D1%81%D0%BA%D0%BE%D0%B3%D0%BE_%D0%B3%D0%BE%D1%81%D1%83%D0%B4%D0%B0%D1%80%D1%81%D1%82%D0%B2%D0%B0_%D0%BD%D0%B0_%D1%80%D1%83%D1%81%D1%81%D0%BA%D0%BE%D0%BC_%D1%8F%D0%B7%D1%8B%D0%BA%D0%B5
Так… это самое… я не видел, как автор реализовал свое кеширование, но если в виде отдельного встраиваемого модуля (если нет, то он ССЗБ), то у него теперь в любом другом проекте на асме тоже займет пару минут на реализацию, так как теперь есть библиотека.
Найденное чужое решение действительно не запоминается, но не в случае, когда ты сам потратил кучу услий на то, чтобы найти решение проблемы, и не преуспел. Важен сам процесс поиска.
Тут надо разделить эмулятор машины и интерпретатор языка. Что bochs, что JVM — эмуляторы машин, кмк.
2)железные JVM
Не совсем верная аналогия. Но о неразумности использования ассемблера я автору неоднократно говорил в предыдуших его темах. Еще раз, на всякий случай: не боритесь против ветряных мельниц, я не говорю, что писать сайты на асм вместо php или Java норма, напротив. Парой сообщений выше я уже написал вам, но вы проигнорировали:
Разумеется! С этим никто не спорит как бы.
Не-а. Автор статьи утверждает, что писать на современном макроассемблере fasm — намного приятнее и проще, чем «встарь». По крайней мере, я именно об этом веду разговор.
Нет, я же говорю вам: использование современного fasm — это уже ближе к C, чем к традиционному ассемблеру. Такие вот проекты — это показывают. А опкоды и адреса вручную — это шаг в противоположную сторону.