Решал я недавно задачку на LeetCode. Вроде, обычная задачка на динамическое программирование, среднего уровня сложности. Но оказалось, что её можно решить и по-другому, существенно уменьшив временную и пространственную сложность.
Пользователь
Раздувание кода стало астрономическим
5 мин
Перевод
Время от времени я пользуюсь одним сервисом: мне нужно загрузить файлы в какое-то место (название сервиса не имеет роли, потому что, откровенно говоря, все они одинаковы). По сути, я просто указываю папку на своём жёстком диске, после чего её содержимое копируется на удалённый сервер, на котором, вероятно, происходит что-то связанное с базами данных — этим файлам присваиваются имена и выполняются проверки того, кто их скачивает.
Сервисом владеет большая компания, поэтому её процессы масштабны; вероятно, её часто пытаются взломать, поэтому требуется какая-то защита, а также проверка того, что файлы никто не модифицировал в промежутке между загрузкой с моего компьютера и получением на сервере. Всё это я понимаю.
… но по сути, речь идёт о том, что нужно зарегистрировать несколько файлов, считать их, загрузить, а затем закрыть соединение и записать в файл лога, всё ли прошло успешно, а если нет, то что именно случилось. В этом нет ничего сложного, и даже я писал с нуля подобный код при помощи Wininet API и PHP на сервере, общающемся с моей базой данных MySQL. Наверно, моя система была не такой надёжной, как системы уровня энтерпрайза, однако поддерживала сотни тысяч загруженных файлов, их верификацию, скачивание и логирование. Наверно, это работа для одного кодера на две-три недели?
Специальный инструмент загрузки на сервер, которым я пользуюсь сегодня, суммарно имеет 230 МБ клиентских файлов и задействует 2,7 тысяч файлов для управления этим процессом.
Си должен умереть
21 мин
Язык Си - один из наиболее влиятельных языков программирования за всю историю. Он стал незаменимым инструментом разработки операционных систем, сместив с этого пьедестала языки ассемблера. Изучение Си обязательно для любого уважающего себя программиста. Этот язык любим за свою внешнюю простоту и ненавидим за беспощадность к ошибкам. Благодаря нему у нас есть ядро Linux и тысячи уязвимостей в нём же в придачу.
Попробуем понять, что же такое этот противоречивый язык Си - благословение или проклятие?
Почему не все сеньоры получают оффер мечты, и что с этим делать
11 мин
На Хабре много познавательных статей про то, «как я собеседовался в X» (раз, два, три, или вот четыре). Часто они написаны с одной стороны баррикад, т.е. со стороны соискателя. Читая очередную, я понял, что мое представление о найме тоже однобоко — и решил воспользоваться служебным положением, чтобы порасспросить HR одного из крупных рекрутинговых агентств, работающих в IT, как все это видится с их стороны.
Итак, ситуация: вполне себе квалифицированный и успешный сеньор хочет устроиться в конкретную большую компанию, собеседуется, проходит все этапы, но оффера так и не видит. Почему? Что он делает не так? Давайте разбираться.
Итак, ситуация: вполне себе квалифицированный и успешный сеньор хочет устроиться в конкретную большую компанию, собеседуется, проходит все этапы, но оффера так и не видит. Почему? Что он делает не так? Давайте разбираться.
Почему технические собеседования не нужны
4 мин
Ремарка - речь пойдет о 98% собеседований в постсоветском пространстве на позицию Java Developer.
Начну вот с чего: знание Collections Framework, его иерархии наследования, внутренней работы HashMap и количества примитивов в языке - никак, совсем никак, не может дать представления о работоспособности человека.
- Фу, какая банальщина, все и так всё понимают. Такие вопросы на собеседованиях дают представление о базовых знаниях человека, а на остальную работу смотрят в период испытательного срока.
Что же, с таким мнением я сталкивался неоднократно и не могу сказать ничего против, но тем не менее, приглашаю вас порассуждать о теме собеседования и разобраться, что с ними не так.
Вот пункты, которые, на мой взгляд, должны лежать в основе построения плана собеседования:
1) Работа разработчика состоит из 40% кодинга и 60% рассуждений, размышлений и попыток понять и вместить задачу, выбрать оптимальный алгоритм ее решения. И я не говорю о созвонах, декомпозиции и обсуждении предстоящего спринта и т.д. и т.п. В таком случае кодинга остается процентов 20.
2) Без грамотного и прозрачного процесса коммуникации между членами команды, проекта не получится. И к сожалению, какой бы прекрасный не был тимлид и ПМ, если разработчики не умеют общаться и понимать, какую информацию важно озвучивать команде, что нужно спрашивать, а что можно загуглить, у проекта будут проблемы.
3) Языки, фреймворки, библиотеки, базы данных и прочее - это всего лишь инструмент для решения проблемы, и он должен быть подобран под задачу, а не наоборот.