Вы на 180° исказили мой комментарий, нехорошо так.
Ещё хуже проводить аналогию между отличниками и неучами, поступившими для откоса от армии и т. п. Я не вхожу в число "непонятно как" учащихся, как вы выразились.
4.5 средний балл с акцентом на профильные дисциплины
Учёба была искренне интересной
Ещё и на рабочую нефтяную специальность выучился.
Тут вообще было бы грех с тройками учиться
Руками же тоже нужно уметь работать, быть ближе к людям
Нет ничего нелогичного в том, что мне жаль мои личные потраченные усилия. Нет ничего нелогичного в том, что я бы от такой помощи персонально мне не отказался.
Лишь единожды пришлось писать. Причём на производственном предприятии.
Ситуация: производственное помещение с огромным количеством металлоконструкций, электрооборудования и передвигающихся металлических устройств. Покрытие Wi-fi в цехе есть, но регулярные короткие обрывы и есть слепые зоны. По цеху ходил специальный сотрудник с ТСД, которым и штрихкоды читает, и вручную данные заносит. Веб-страница прежнего приложения регулярно выдавала: "Веб-страница не отвечает".
Ну а PWA сохраняет данные у себя локально, когда сигнал потерян, а при появлении синхронизируется. В общем-то большая часть функциональности складских и контролирующих сотрудников покрывается.
Для решения одной-единственной задачи - трудоустройства. Но тут палка о двух концах: с одной стороны выпускники однозначно получат работу и опыт по специальности, а с другой - принудиловка опять закончится выполнением показателей ради галочки для тех, кто ответственный за это распределение.
P. S. Не назову себя сторонником распределения, но сам бы после вуза от него не отказался. Хотя бы эту работу попробовал. Мне до сих пор обидно, что столько лет обучался на интересной для меня специальности, но ни разу не попал даже на собеседование. Вот и гадаю теперь - это упущенная возможность, или везение? Каково это вообще в геофизике работать?
Кстати, да. Многие профессии не могут эффективно обойтись без помощников. Постоянных. Теперь даже уверен, что врач - одна из таких.
Не уверен, но у судебно-медицинских экспертов помощник - человек обязательный и занимается как раз оформлением/секретарством/сопроводительством. По крайней мере я столкнулся именно с таким случаем.
Мой путь "к технике" тоже начался с декомпозиции проекта на части. Правда, начинать пришлось не с робота, а обычного ленточного транспортёра. Для начинающего меня этот этап простым тогда не казался. Это сильно отличалось от написания кода в моей работе :-)
Затем к транспортёру добавил сканер, считывающий штрихкоды с проезжающего товара. А теперь возникла потребность в фотодатчике. Потом, подозреваю, нужно будет пневмоцилиндр к транспортёрной ленте приспособить, чтобы сталкивал с неё товар, который не удалось прочитать. Для кого-то это работы на полдня, наверное. Зато интересно!
Попробую поделиться своим опытом, но почти без кода.
Первой из них я прочитал "Чистый код" Мартина. На тот момент я ещё не работал программистом и в анамнезе было всего пара программ (генератор контрольных работ, небольшая программа для одной компании ЖКХ и мелочи-мелочи). Их было тяжело поддерживать, а код - забористая наркомания. Из-за них я тогда решил, что не буду работать программистом. Книгу прочитал случайно и мнение поменял. Для меня в то время было открытием (ДА! Открытием!), что переменные можно называть не a, b, n1, x_, а осмысленно, причём более осмысленно, чем quantity, volume и т. п. Сейчас это уже кажется смешным :-) Всё, описанное в книге теперь кажется тривиальным, очевидным и банальным.
Далее я прочитал "Чистую архитектуру", но к тому моменту я уже работал программистом и не скажу, что она оказала революционное влияние на мою работу. Скорее устаканила и систематизировала то, с чем я уже столкнулся.
Ну а книга "Грокаем алгоритмы", на удивление, несмотря на свою детскость, буквально недавно принесла мне небольшую премию чуть меньше 80 тыс. Я умудрился успешно применить алгоритм k-ближайших соседей для оптимизации работы склада. Хотя сейчас понимаю, что симплекс-метод подошёл бы явно лучше. На тот момент я его не знал, а в книге он не описывался.
P. S. Паттерны проектирования только открыл, но как-то отложил до лучших времён.
Проблема была такая: оптимизировать размещение товаров на складе.
Один из критериев оптимальности - размещение в одной ячейке товаров с непохожими названиями. В противном случае встречается такая ситуация:
сборщику товара приказали собрать 14 упаковок 5-мл. шприцов по 10 шт. от производителя ООО "АБВГД".
он подходит к нужной ячейке, а там десятки разновидностей в общем-то одинаковых шприцов: есть 5 мл по 10 шт, но другой производитель, есть тот же производитель, но 10 мл. по 5 штук и т. п.
сборщик путается, берёт не тот товар, в итоге это оборачивалось штрафом для него и недовольством для клиента
если в ячейке лежат непохожие товары: один вид перчаток, один вид витаминок, один вид противовирусного и лишь один вид шприцов, то сборщику ошибиться гораздо тяжелее.
Хорошо получилось! Как-то тоже пришлось дорабатывать алгоритм Левенштейна под свои нужды. Причина была такая же - алгоритм хорошо сравнивает два отдельных слова, а вот два предложения - уже не очень. Кратко о том, к чему я пришёл в тот раз:
в сравниваемых текстах идентичные слова исключались из сравнения
оставшиеся слова перед сравнением сортировались по алфавиту, так как порядок слов не был важен в моей предметной области
полученное расстояние нормировалось на исходную длину строк, включая исключённые на первом этапе слова
Что интересно, в комментариях отметился ещё один разработчик, который в той же предметной области решал похожую проблему и тоже использовал расстояние Левенштейна.
Энциклопедии "Аванта+" - это ваша работа, выходит? Хорошая серия! Жаль, в детстве не все купил, хотя они мне очень нравились.
А по теме статьи. Есть у меня пример небольшого ларька, который часть своего товара реализует постоянной группе клиентов (человек 60-70, назовём их группой "X") через заказы в мессенджере. У них предварительная устная договорённость. Эти группа "X" получает свой купленный товар быстрей, чем те, кто в живой очереди, а собственник получает возможность комплектовать эти заказы заранее, ещё до прихода группы "X".
Из-за этого на кассе ларька стало хватать одного кассира, а не двух. Зарплату "сэкономленного" кассира собственник поделил условно пополам: часть себе в прибыль, часть - скидка каждому только в группе "X".
Добрый вечер! Первую ещё читаю, прочитал около трети. Оценю её на 4. В целом она полезная и приближена к практике, но многословна.
Вторая ещё не распакована и не читал. Специально для вас могу начать читать её следующей :-) Пока что в очереди следующей оставалась "Масштабируемый рефакторинг".
В том-то и дело, что внутри setMode() не вызывается ни одна из функций ниже :-)
Покажу на абстрактном примере иначе. Допустим, есть форма, которую нужно иногда показывать, иногда скрывать. Для этого у неё есть булевое свойство visible.
Первый джун придерживается такого стиля:
public function visible($bool)
{
$this->visible = $bool;
}
// в разных местах проекта, соответственно, вызывается так:
visible(true);
// либо:
visible(false);
Второй джун придерживается стиля с говорящими названиями:
public function show()
{
$this->visible = true;
}
public function hide()
{
$this->visible = false;
}
первый код допускает некоторую моду по умолчанию, а второй — нет.
Вот с этим нельзя не согласиться. Пожалуй, главный аргумент (не в контексте нашего проекта, правда).
А вот с первым и вторым пунктом нельзя однозначно согласиться. При добавлении, например, нового режима "Валидация продукции на линии" никакой проблемы нет. Незачем изучать код остальных режимов. Их изучение даст ответ на вопрос: "Как?", но не: "Почему?", а будет именно такой вопрос.
P. S. А поделитесь опытом, как бы сделали вы? Мне тоже полезно, видимо)
Пример всё же будет лучше. Есть некая служба, работающая с неподконтрольным нам API (отдаёт в ответ на запросы документы разной структуры). Работа API зависит от т. н. режима работы. Бывают режим "Цех", "Производственная линия" и "Отдел планирования".
Для активации режима один джун написал одну такую функцию:
public function setMode($mode)
{
// Тут какой-то switch + case для переменной $mode, емнип.
// В сумме строчек 20
}
Другой наш джун написал три разных функции:
public function setWorkshopMode() // внутри несколько строк
public function setManufacturingLineMode() // аналогична предыдущей
public function setPlanningDepartmentMode() // эта тоже единообразна
Многие книги "заходят" программисту "А", но не заходят программисту "Б". Поэтому книг придётся читать много и многие из них лично вам не понравятся, но это нормально.
Купить можно много чего. Извиняюсь за качество фото
Я бы добавил к предыдущему комментарию "Чистый код" Роберта Мартина. Из всех его книг мой уровень подняла только эта.
Одна книга на любую тему даст большую фору десяти статьям этой же темы, поэтому лучше делать акцент именно на книгах, а статьями уже "оттачивать" полученный навык.
Но одних книг мало. Их ценность без практики околонулевая, поэтому нужно много программировать. Практика практике - рознь. Лучшая - это когда вы долго-долго поддерживаете какой-то проект. На поддержке вы получите более ценный опыт, чем на разработке с нуля.
Неплохая, кстати, книга. Успел даже один из её рецептов на работе применить в процессе рефакторинга. Может кому тоже полезно будет поэкспериментировать?
Рецепт основан на правиле "мозг может одновременно удерживать не более 7 объектов". Во время рефакторинга нескольких моделей пробовал переписывать функции так, чтобы в них было 5-6 (до 7) сущностей. По ощущениям получилось неплохо, хотя и ничего революционного.
P. S. Прочитал, наверное, только четверть книги. В целом поставил бы 5, но иногда слишком многословно.
Это боль! Вы правы. Приходится совмещать разные инструменты: где-то я всё же использую bash, но при каждой возможности соскакиваю на какой-нибудь другой скриптовый из имеющихся.
Вы чего это на меня наговариваете? Это неправда:
Вы на 180° исказили мой комментарий, нехорошо так.
Ещё хуже проводить аналогию между отличниками и неучами, поступившими для откоса от армии и т. п. Я не вхожу в число "непонятно как" учащихся, как вы выразились.
4.5 средний балл с акцентом на профильные дисциплины
Ещё и на рабочую нефтяную специальность выучился.
Тут вообще было бы грех с тройками учиться
Нет ничего нелогичного в том, что мне жаль мои личные потраченные усилия. Нет ничего нелогичного в том, что я бы от такой помощи персонально мне не отказался.
Лишь единожды пришлось писать. Причём на производственном предприятии.
Ситуация: производственное помещение с огромным количеством металлоконструкций, электрооборудования и передвигающихся металлических устройств. Покрытие Wi-fi в цехе есть, но регулярные короткие обрывы и есть слепые зоны. По цеху ходил специальный сотрудник с ТСД, которым и штрихкоды читает, и вручную данные заносит. Веб-страница прежнего приложения регулярно выдавала: "Веб-страница не отвечает".
Ну а PWA сохраняет данные у себя локально, когда сигнал потерян, а при появлении синхронизируется. В общем-то большая часть функциональности складских и контролирующих сотрудников покрывается.
Для решения одной-единственной задачи - трудоустройства. Но тут палка о двух концах: с одной стороны выпускники однозначно получат работу и опыт по специальности, а с другой - принудиловка опять закончится выполнением показателей ради галочки для тех, кто ответственный за это распределение.
P. S. Не назову себя сторонником распределения, но сам бы после вуза от него не отказался. Хотя бы эту работу попробовал. Мне до сих пор обидно, что столько лет обучался на интересной для меня специальности, но ни разу не попал даже на собеседование. Вот и гадаю теперь - это упущенная возможность, или везение? Каково это вообще в геофизике работать?
Кстати, да. Многие профессии не могут эффективно обойтись без помощников. Постоянных. Теперь даже уверен, что врач - одна из таких.
Не уверен, но у судебно-медицинских экспертов помощник - человек обязательный и занимается как раз оформлением/секретарством/сопроводительством. По крайней мере я столкнулся именно с таким случаем.
Не-не-не, к юмору определённо претензий нет и быть не может. В этом смысле статья на 5+.
Коллега, вероятно, имеет в виду абзацы, пунктуацию. Но с этим лучше бороться через ctrl+Enter, конечно же.
Мой путь "к технике" тоже начался с декомпозиции проекта на части. Правда, начинать пришлось не с робота, а обычного ленточного транспортёра. Для начинающего меня этот этап простым тогда не казался. Это сильно отличалось от написания кода в моей работе :-)
Затем к транспортёру добавил сканер, считывающий штрихкоды с проезжающего товара. А теперь возникла потребность в фотодатчике. Потом, подозреваю, нужно будет пневмоцилиндр к транспортёрной ленте приспособить, чтобы сталкивал с неё товар, который не удалось прочитать. Для кого-то это работы на полдня, наверное. Зато интересно!
Ну, у Роберта Мартина и правда можно недостатки найти, но и без них критиканты всегда найдутся. И для любого автора, тем более настолько известного.
Как бы то ни было - читать всё равно полезно. Главное читать достаточно много, чтобы сложилась картина.
Попробую поделиться своим опытом, но почти без кода.
Первой из них я прочитал "Чистый код" Мартина. На тот момент я ещё не работал программистом и в анамнезе было всего пара программ (генератор контрольных работ, небольшая программа для одной компании ЖКХ и мелочи-мелочи). Их было тяжело поддерживать, а код - забористая наркомания. Из-за них я тогда решил, что не буду работать программистом. Книгу прочитал случайно и мнение поменял. Для меня в то время было открытием (ДА! Открытием!), что переменные можно называть не a, b, n1, x_, а осмысленно, причём более осмысленно, чем quantity, volume и т. п. Сейчас это уже кажется смешным :-) Всё, описанное в книге теперь кажется тривиальным, очевидным и банальным.
Далее я прочитал "Чистую архитектуру", но к тому моменту я уже работал программистом и не скажу, что она оказала революционное влияние на мою работу. Скорее устаканила и систематизировала то, с чем я уже столкнулся.
Ну а книга "Грокаем алгоритмы", на удивление, несмотря на свою детскость, буквально недавно принесла мне небольшую премию чуть меньше 80 тыс. Я умудрился успешно применить алгоритм k-ближайших соседей для оптимизации работы склада. Хотя сейчас понимаю, что симплекс-метод подошёл бы явно лучше. На тот момент я его не знал, а в книге он не описывался.
P. S. Паттерны проектирования только открыл, но как-то отложил до лучших времён.
Проблема была такая: оптимизировать размещение товаров на складе.
Один из критериев оптимальности - размещение в одной ячейке товаров с непохожими названиями. В противном случае встречается такая ситуация:
сборщику товара приказали собрать 14 упаковок 5-мл. шприцов по 10 шт. от производителя ООО "АБВГД".
он подходит к нужной ячейке, а там десятки разновидностей в общем-то одинаковых шприцов: есть 5 мл по 10 шт, но другой производитель, есть тот же производитель, но 10 мл. по 5 штук и т. п.
сборщик путается, берёт не тот товар, в итоге это оборачивалось штрафом для него и недовольством для клиента
если в ячейке лежат непохожие товары: один вид перчаток, один вид витаминок, один вид противовирусного и лишь один вид шприцов, то сборщику ошибиться гораздо тяжелее.
Хорошо получилось! Как-то тоже пришлось дорабатывать алгоритм Левенштейна под свои нужды. Причина была такая же - алгоритм хорошо сравнивает два отдельных слова, а вот два предложения - уже не очень. Кратко о том, к чему я пришёл в тот раз:
в сравниваемых текстах идентичные слова исключались из сравнения
оставшиеся слова перед сравнением сортировались по алфавиту, так как порядок слов не был важен в моей предметной области
полученное расстояние нормировалось на исходную длину строк, включая исключённые на первом этапе слова
Что интересно, в комментариях отметился ещё один разработчик, который в той же предметной области решал похожую проблему и тоже использовал расстояние Левенштейна.
Энциклопедии "Аванта+" - это ваша работа, выходит? Хорошая серия! Жаль, в детстве не все купил, хотя они мне очень нравились.
А по теме статьи. Есть у меня пример небольшого ларька, который часть своего товара реализует постоянной группе клиентов (человек 60-70, назовём их группой "X") через заказы в мессенджере. У них предварительная устная договорённость. Эти группа "X" получает свой купленный товар быстрей, чем те, кто в живой очереди, а собственник получает возможность комплектовать эти заказы заранее, ещё до прихода группы "X".
Из-за этого на кассе ларька стало хватать одного кассира, а не двух. Зарплату "сэкономленного" кассира собственник поделил условно пополам: часть себе в прибыль, часть - скидка каждому только в группе "X".
Можно это назвать импакт-предпринимательством?
Добрый вечер! Первую ещё читаю, прочитал около трети. Оценю её на 4. В целом она полезная и приближена к практике, но многословна.
Вторая ещё не распакована и не читал. Специально для вас могу начать читать её следующей :-) Пока что в очереди следующей оставалась "Масштабируемый рефакторинг".
В том-то и дело, что внутри setMode() не вызывается ни одна из функций ниже :-)
Покажу на абстрактном примере иначе. Допустим, есть форма, которую нужно иногда показывать, иногда скрывать. Для этого у неё есть булевое свойство visible.
Первый джун придерживается такого стиля:
Второй джун придерживается стиля с говорящими названиями:
Отлично! Что-то похожее у нас реализовано при изменении даты, когда без остановки линии печатаем новую дату производства после 23:59:59. Спасибо.
Вот с этим нельзя не согласиться. Пожалуй, главный аргумент (не в контексте нашего проекта, правда).
А вот с первым и вторым пунктом нельзя однозначно согласиться. При добавлении, например, нового режима "Валидация продукции на линии" никакой проблемы нет. Незачем изучать код остальных режимов. Их изучение даст ответ на вопрос: "Как?", но не: "Почему?", а будет именно такой вопрос.
P. S. А поделитесь опытом, как бы сделали вы? Мне тоже полезно, видимо)
Пример всё же будет лучше. Есть некая служба, работающая с неподконтрольным нам API (отдаёт в ответ на запросы документы разной структуры). Работа API зависит от т. н. режима работы. Бывают режим "Цех", "Производственная линия" и "Отдел планирования".
Для активации режима один джун написал одну такую функцию:
Другой наш джун написал три разных функции:
Вам чей код больше по нраву и почему?
Наслышан об этом. Уже не удивляет наличие двух прямо противоположных точек зрения об этом авторе.
А вы в книге "Чистый код" что-то полезное всё-таки нашли, или вообще ни одной полезной мысли? Лично мне зашла глава о функциях.
Многие книги "заходят" программисту "А", но не заходят программисту "Б". Поэтому книг придётся читать много и многие из них лично вам не понравятся, но это нормально.
Купить можно много чего. Извиняюсь за качество фото
Я бы добавил к предыдущему комментарию "Чистый код" Роберта Мартина. Из всех его книг мой уровень подняла только эта.
Одна книга на любую тему даст большую фору десяти статьям этой же темы, поэтому лучше делать акцент именно на книгах, а статьями уже "оттачивать" полученный навык.
Но одних книг мало. Их ценность без практики околонулевая, поэтому нужно много программировать. Практика практике - рознь. Лучшая - это когда вы долго-долго поддерживаете какой-то проект. На поддержке вы получите более ценный опыт, чем на разработке с нуля.
Неплохая, кстати, книга. Успел даже один из её рецептов на работе применить в процессе рефакторинга. Может кому тоже полезно будет поэкспериментировать?
Рецепт основан на правиле "мозг может одновременно удерживать не более 7 объектов". Во время рефакторинга нескольких моделей пробовал переписывать функции так, чтобы в них было 5-6 (до 7) сущностей. По ощущениям получилось неплохо, хотя и ничего революционного.
P. S. Прочитал, наверное, только четверть книги. В целом поставил бы 5, но иногда слишком многословно.
Это боль! Вы правы. Приходится совмещать разные инструменты: где-то я всё же использую bash, но при каждой возможности соскакиваю на какой-нибудь другой скриптовый из имеющихся.