https://smart-heads.com/
https://gapopa.com/
Нам очень нужны толковые ребята
- с опытом работы PHP программистом более 1 года;
- с уверенным владением PHP, HTML, CSS, JavaScript, MySQL;
- с опытом и пониманием принципов проектирования структур баз данных;
- с пониманием принципов объектно-ориентированного дизайна программ;
- с умением использовать операционные системы типа *nix;
- с владением Git и пониманием принципов Git Flow;
- с умением работать в команде, желанием перенимать опыт коллег и делиться собственным опытом;
- с терпеливым отношением к чужому коду и к критике собственного;
- с умением читать и понимать техническую литературу на английском языке;
- с наличием широкого Интернет-канала и настроенной программы Skype, позволяющих поддерживать качественную видеосвязь;
- приветствуется понимание TDD, BDD, опыт автоматизированного тестирования;
- приветствуется опыт работы с другими языками Python, Ruby, Go, Dart, TypeScript, ActionScript;
- приветствуется опыт работы с технологиями Memcached, Redis, RabbitMQ, MongoDB, Cassandra.
Мы не сработаемся, если:
- Вы недостаточно самостоятельны и боитесь нести ответственность за принятое Вами решение;
- Вы любитель часами обсуждать поставленную перед Вами задачу;
- Вы страдаете от недостатка общения и приходите на работу, чтобы просто пообщаться с коллегами;
- Вы через каждые 5 минут бегаете покурить или выпить чашку кофе/чая;
- программирование является для Вас всего лишь хобби;
- Вы считаете, что написание дизайнерской и технической частей должны осуществлять разные люди;
- Вы нуждаетесь в специалистах по качеству, тестерах и т.п.;
- Вы считаете, что ООП или использование фреймворков - вершина развития веб-программирования;
- Вы считаете дисциплину пустым звуком;
- Вы считаете себя единственным и незаменимым;
- Вы не готовы адекватно принимать критику в свой адрес;
- Вы не готовы развиваться как программист и личность;
- Вы любитель к месту и не к месту использовать чужие коды вместо того, чтобы подумать собственной головой.
Условия:
- начальная ставка заработной платы 1500 EUR (8 часов), 1125 EUR (6 часов) или 750 EUR (4 часа);
- заработная плата зачисляется на Ваш лицевой счет ежедневно;
- периодичность заказа выплат решаете самостоятельно (не чаще 1 раза в сутки);
- рабочий день - 4, 6 или 8 часов по Вашему выбору, с понедельника по пятницу;
- в рабочее время Вы обязаны раз в минуту делать скриншот Вашего экрана (ПО по Вашему выбору). По окончании рабочего дня архив со скриншотами выкладывается на сервер;
- Вы несете персональную ответственность за каждый баг, который выгружаете. Ваши коды должны соответствовать требованиям качества (архитектура и форматирование кода). Вас никто не торопит. Не спешите - пишите и тестируйте качественно;
- система штрафов проста и понятна: опоздали на минуту (выгрузили баг) - минус евро, второй раз - минус 2, третий раз - минус 4. Если человек даже после этого не понимает, с ним расстаются.
Вывод:
Вам честно платят - Вы честно работаете. Да, условия жесткие, но здесь платят не за отсиженное, а за отработанное время. Мы понимаем, что может быть тяжело работать 8 часов подряд в таком режиме. Тяжело Вам работать в таком режиме 8 часов - работайте 6 часов или 4. Но работайте.
P.S. Любителям писать на форумах отвечаем: за всю историю не было случая, чтобы заработную плату не только не выплатили, но даже задержали. Если Вас не взяли после собеседования или уволили спустя неделю работы, значит, Вы не сумели делом доказать свою профпригодность. Между сказать и сделать огромная дистанция.
- Допустим, я решил присоединиться к вашей команде. Что мне делать дальше?
- Пожалуйста, оставьте заявку, в ответ на которую Вам будет выслано небольшое тестовое задание, чтобы убедиться на деле, что уровень Вашей квалификации, степень кропотливости и отношение к работе соответствуют тому, что нужно нам. Такие вещи должны быть доказаны делом.
https://gapopa.com/
Нам очень нужны толковые ребята
- с опытом работы PHP программистом более 1 года;
- с уверенным владением PHP, HTML, CSS, JavaScript, MySQL;
- с опытом и пониманием принципов проектирования структур баз данных;
- с пониманием принципов объектно-ориентированного дизайна программ;
- с умением использовать операционные системы типа *nix;
- с владением Git и пониманием принципов Git Flow;
- с умением работать в команде, желанием перенимать опыт коллег и делиться собственным опытом;
- с терпеливым отношением к чужому коду и к критике собственного;
- с умением читать и понимать техническую литературу на английском языке;
- с наличием широкого Интернет-канала и настроенной программы Skype, позволяющих поддерживать качественную видеосвязь;
- приветствуется понимание TDD, BDD, опыт автоматизированного тестирования;
- приветствуется опыт работы с другими языками Python, Ruby, Go, Dart, TypeScript, ActionScript;
- приветствуется опыт работы с технологиями Memcached, Redis, RabbitMQ, MongoDB, Cassandra.
Мы не сработаемся, если:
- Вы недостаточно самостоятельны и боитесь нести ответственность за принятое Вами решение;
- Вы любитель часами обсуждать поставленную перед Вами задачу;
- Вы страдаете от недостатка общения и приходите на работу, чтобы просто пообщаться с коллегами;
- Вы через каждые 5 минут бегаете покурить или выпить чашку кофе/чая;
- программирование является для Вас всего лишь хобби;
- Вы считаете, что написание дизайнерской и технической частей должны осуществлять разные люди;
- Вы нуждаетесь в специалистах по качеству, тестерах и т.п.;
- Вы считаете, что ООП или использование фреймворков - вершина развития веб-программирования;
- Вы считаете дисциплину пустым звуком;
- Вы считаете себя единственным и незаменимым;
- Вы не готовы адекватно принимать критику в свой адрес;
- Вы не готовы развиваться как программист и личность;
- Вы любитель к месту и не к месту использовать чужие коды вместо того, чтобы подумать собственной головой.
Условия:
- начальная ставка заработной платы 1500 EUR (8 часов), 1125 EUR (6 часов) или 750 EUR (4 часа);
- заработная плата зачисляется на Ваш лицевой счет ежедневно;
- периодичность заказа выплат решаете самостоятельно (не чаще 1 раза в сутки);
- рабочий день - 4, 6 или 8 часов по Вашему выбору, с понедельника по пятницу;
- в рабочее время Вы обязаны раз в минуту делать скриншот Вашего экрана (ПО по Вашему выбору). По окончании рабочего дня архив со скриншотами выкладывается на сервер;
- Вы несете персональную ответственность за каждый баг, который выгружаете. Ваши коды должны соответствовать требованиям качества (архитектура и форматирование кода). Вас никто не торопит. Не спешите - пишите и тестируйте качественно;
- система штрафов проста и понятна: опоздали на минуту (выгрузили баг) - минус евро, второй раз - минус 2, третий раз - минус 4. Если человек даже после этого не понимает, с ним расстаются.
Вывод:
Вам честно платят - Вы честно работаете. Да, условия жесткие, но здесь платят не за отсиженное, а за отработанное время. Мы понимаем, что может быть тяжело работать 8 часов подряд в таком режиме. Тяжело Вам работать в таком режиме 8 часов - работайте 6 часов или 4. Но работайте.
P.S. Любителям писать на форумах отвечаем: за всю историю не было случая, чтобы заработную плату не только не выплатили, но даже задержали. Если Вас не взяли после собеседования или уволили спустя неделю работы, значит, Вы не сумели делом доказать свою профпригодность. Между сказать и сделать огромная дистанция.
- Допустим, я решил присоединиться к вашей команде. Что мне делать дальше?
- Пожалуйста, оставьте заявку, в ответ на которую Вам будет выслано небольшое тестовое задание, чтобы убедиться на деле, что уровень Вашей квалификации, степень кропотливости и отношение к работе соответствуют тому, что нужно нам. Такие вещи должны быть доказаны делом.
Smart-Heads
Smart-Heads.Com - programmers live here. Smart heads are welcome.
Forwarded from запуск завтра
Сегодня я видел небольшой самодельный ERP (много мелких крудов типа оформления отпуска) на скале, с Кафкой и Кассандрой. Там есть блоги. На скале.
А вчера — высоконагруженное e-commerce решение с ядром на битриксе.
Не могу решить, что мне нравится больше 👀
Мой учитель по психотерапии говорит, что почти в каждом терапевте есть мазохистическая часть личности, иначе в профессии делать нечего. В IT-аудите — похожая история.
Ещё круто, что как не издевайся над здравым смыслом — все равно ведь работает и даже деньги зарабатывает. Мир шире и богаче, чем я себе представлял.
А вчера — высоконагруженное e-commerce решение с ядром на битриксе.
Не могу решить, что мне нравится больше 👀
Мой учитель по психотерапии говорит, что почти в каждом терапевте есть мазохистическая часть личности, иначе в профессии делать нечего. В IT-аудите — похожая история.
Ещё круто, что как не издевайся над здравым смыслом — все равно ведь работает и даже деньги зарабатывает. Мир шире и богаче, чем я себе представлял.
Forwarded from Aλiaksandr Siamionau
ФП даёт достаточное количество гарантий, чтобы не писать юнит тесты вообще. Лучше интеграционные, они очень полезны
https://www.hackster.io/news/the-lisperati1000-is-a-cyberdeck-terminal-dedicated-to-lisp-programming-bb564f2ffcff
If you’re new to coding and want something easy to use, Python is great. For performance and capability, it’s hard to beat programming in C. But if you need some complex algorithms — particularly algorithms that do a lot of heavy mathematical lifting — then Lisp is the ideal choice.
If you’re new to coding and want something easy to use, Python is great. For performance and capability, it’s hard to beat programming in C. But if you need some complex algorithms — particularly algorithms that do a lot of heavy mathematical lifting — then Lisp is the ideal choice.
Hackster.io
The Lisperati1000 Is a Cyberdeck Terminal Dedicated to Lisp Programming
Dr. Conrad Barski wanted a small, portable device for coding Lisp on the go and built the Lisperati1000 cyberdeck terminal for the job.
Forwarded from {^~^}
Проблема не в академиках, а в фундаментальном непонимании, что язык такое. Что сокращение кода — не цель. Единственная цель — читабельность кода, быстрая и однозначная. Сокращение этому не поможет, если оно не даёт компактности записи, а оно не даёт. С точки зрения человека пустое пространство — мусор для зрительной памяти, а вот механизмы очистки от этого мусора, мягко скажем, ДРУГИЕ, чем те что предполагает язык. В результате код воспринимается по внешнему виду, и это восприятие доминирует. Читаются совсем другие связи, чем те что будут прочитаны машиной. В результате ошибки не видны.
Появление ошибок в процессе написания кода процесс естественный, большинство из них обычные опечатки и исправляются сразу же. Но не в Скале. В Скале механизм памяти привыкает к потоку паразитно распознаваемому мусору, в результате механизм памяти в принципе считает поток мусора естественным, становясь толерантным к ошибкам.
Примерно так же вы толерантны к ошибкам в естественном языке. Почему и говорю, в эту Скалу осталось добавить неправильные глаголы и нечитаемые согласные, чтобы угробить окончательно. Только в отличие от естественных языков, где людям тупо приходится подчиняться большинству, Скала явно не в этом большинстве. А потому, глупость построения языка не простят. Как вы бы не простили тройную горчицу и красный перец в лазанье, добавленные без вашего запроса, но по мнению повара который считает что так лучше.
В отличие от естественных языков, языки программирования не имеют избыточности. Ошибка будет ошибкой, если ошибки пропускать, код будет дерьмом. А делать из дерьма конфетку — да, это наша профессия, а потому и разбираться в сортах дерьма тоже.
По той же причине я против засилия синтаксического сахара и в Java. Да, код выходит короче, но в отличие от компилятора, читатель не может сделать «подковёрную работу» со сколь-либо вменяемой скоростью. А читать-то надо раз в 100 быстрее, чем код пишется. И что ещё важнее, в 100 раз чаще. Сокращение скорости написания ценой снижения читабельности — это тот самый «нинзя-кодинг», то есть саботаж, отравление проекта. И в отличие от прямой обфускации, не даёт права потом принять решение всё переписать как надо, типа там же всё хорошо. Прекрасная маркиза.
Появление ошибок в процессе написания кода процесс естественный, большинство из них обычные опечатки и исправляются сразу же. Но не в Скале. В Скале механизм памяти привыкает к потоку паразитно распознаваемому мусору, в результате механизм памяти в принципе считает поток мусора естественным, становясь толерантным к ошибкам.
Примерно так же вы толерантны к ошибкам в естественном языке. Почему и говорю, в эту Скалу осталось добавить неправильные глаголы и нечитаемые согласные, чтобы угробить окончательно. Только в отличие от естественных языков, где людям тупо приходится подчиняться большинству, Скала явно не в этом большинстве. А потому, глупость построения языка не простят. Как вы бы не простили тройную горчицу и красный перец в лазанье, добавленные без вашего запроса, но по мнению повара который считает что так лучше.
В отличие от естественных языков, языки программирования не имеют избыточности. Ошибка будет ошибкой, если ошибки пропускать, код будет дерьмом. А делать из дерьма конфетку — да, это наша профессия, а потому и разбираться в сортах дерьма тоже.
По той же причине я против засилия синтаксического сахара и в Java. Да, код выходит короче, но в отличие от компилятора, читатель не может сделать «подковёрную работу» со сколь-либо вменяемой скоростью. А читать-то надо раз в 100 быстрее, чем код пишется. И что ещё важнее, в 100 раз чаще. Сокращение скорости написания ценой снижения читабельности — это тот самый «нинзя-кодинг», то есть саботаж, отравление проекта. И в отличие от прямой обфускации, не даёт права потом принять решение всё переписать как надо, типа там же всё хорошо. Прекрасная маркиза.
Forwarded from Alexey Novoselov
имхо статическая типизация была придумана в ЯП как костыль, чтобы правильно выделять и освобождать память. И ведь к этому костылю все настолько привыкли, что считают это необходимостью. Да, она позволяет во время компиляции оптимизировать код и отловить 1% ошибок с неправильной передачей параметров. Но чем более высокоуровневый язык, тем меньше пользы и больше головной боли от статики. Для эрланга это вообще бесполезная если даже не вредная хрень. Хотя диалайзер - отличная штука и часто выручает
Forwarded from Prokhor Vernikovsky
Типа такого нарисуешь, потом понятней, как писать)
Forwarded from {^~^}
На текущий момент, используя тесты около 8 лет, с разной интенсивностью, могу сказать следующее: Имеет смысл покрывать тестами только переиспользуемый код. Какие-то функции ядра вашего приложения. То, что вызывается из множества мест вашего приложения. Или тестом стоит фиксировать сложно уловимый баг.
Конечный код, который формирует http ответ, или рисует гуй или ещё что-то тестировать смысла нет. И вот теперь почему:
1. Тесты это действительно код, и код которые требует затрат на содержание.
2. Количество тестов растёт. И затраты на них тоже. Часто можно обнаружить что тесты растут быстрее самого приложения. Мы очень редко удаляем код, в тесты удаляются ещё реже. Когда есть тысяча работающих тестов, никто не пойдёт удалить 500 из них. Да, начинается деление на сьюты постоянных и страховочных, но затраты на содержание никуда не уходят.
Ну и самый главный вопрос, сколько тестов писать: ровно столько, сколько нужно для вашей персональной уверенности, с небольшой оглядкой на команду. В идеале тестов должно быть столько чтобы каждый член команды был уверен что всё ок. И это не 100% покрытие Это скорее что-то около 10%. Ядра системы как правила меньше чем куча нашлёпок по интеграции внешних апи, гуи и прочего одноразового кода. Чем чаще что-то меняется тем нужнее там тест(и помните что цена растёт с частотой изменений). А чем больше тестов, тем выше цена поддержки. Таким образом стоимость поддержки тестов на часто меняющуюся систему растёт, от времени, сверхлинейно, и никогда не имеет тенденций к снижению.
Конечный код, который формирует http ответ, или рисует гуй или ещё что-то тестировать смысла нет. И вот теперь почему:
1. Тесты это действительно код, и код которые требует затрат на содержание.
2. Количество тестов растёт. И затраты на них тоже. Часто можно обнаружить что тесты растут быстрее самого приложения. Мы очень редко удаляем код, в тесты удаляются ещё реже. Когда есть тысяча работающих тестов, никто не пойдёт удалить 500 из них. Да, начинается деление на сьюты постоянных и страховочных, но затраты на содержание никуда не уходят.
Ну и самый главный вопрос, сколько тестов писать: ровно столько, сколько нужно для вашей персональной уверенности, с небольшой оглядкой на команду. В идеале тестов должно быть столько чтобы каждый член команды был уверен что всё ок. И это не 100% покрытие Это скорее что-то около 10%. Ядра системы как правила меньше чем куча нашлёпок по интеграции внешних апи, гуи и прочего одноразового кода. Чем чаще что-то меняется тем нужнее там тест(и помните что цена растёт с частотой изменений). А чем больше тестов, тем выше цена поддержки. Таким образом стоимость поддержки тестов на часто меняющуюся систему растёт, от времени, сверхлинейно, и никогда не имеет тенденций к снижению.
Forwarded from m_Rassska
Хз, что вы там настраиваете, обычно процесс ознакомления с софтом == 2 недели + 2 недельки немного поковырять что-то, не больше...
Forwarded from Vasiliy
чтобы хорошо программировать на scala надо убить лет 10 на ассемблере
Forwarded from Timur Latypoff
Ещё интересно узнать ваш опыт программирования.
Всё-таки DI, IoC, синглтоны, графы, гарантии — это всё-таки понятия из области знаний Джуниор-программистов. А программирование на уровне структур данных, минимальная абстракция, простота, иммутабельность, робастность системы, понимание задачи клиента — это входит в лексикон разработчика на году 10—15-м коммерческой работы.
Возможно, из-за этого тоже недопонимание в треде.
Всё-таки DI, IoC, синглтоны, графы, гарантии — это всё-таки понятия из области знаний Джуниор-программистов. А программирование на уровне структур данных, минимальная абстракция, простота, иммутабельность, робастность системы, понимание задачи клиента — это входит в лексикон разработчика на году 10—15-м коммерческой работы.
Возможно, из-за этого тоже недопонимание в треде.
Forwarded from Timur Latypoff
«Структуры данных» — я не имел в виду уровня интервью для приёма на первую работу типа «инвертируй красно-чёрное дерево». Я писал про структуру данных системы: архитектура, преобразования, зависимости, выбранные ограничения и пределы абстракции.
Forwarded from Anton Kucherov
Классный пост, именно так свою инфоцыганщину сейчас продают адепты pure FP парадигмы. 🙂 «Нет времени объяснять, надо все переписать на pure FP, и сразу заживем. 🤷♂️»
Всегда смешно с программистов фронтенда, которые молятся на нетипизированный на стадии компиляции код.
Вы литералли берёте статически типизированные данные со статически типизированной Java на бэкенде, упакованные в статически типизированный Protobuf, переданный по сети, динамически типизированным протоколом HTTP, меняете два поля и отправляете назад в статически типизированную SQL базу данных через статически типизированный запрос.
Просто абсолютный ноль рефлексии у чуваков.
Вы литералли берёте статически типизированные данные со статически типизированной Java на бэкенде, упакованные в статически типизированный Protobuf, переданный по сети, динамически типизированным протоколом HTTP, меняете два поля и отправляете назад в статически типизированную SQL базу данных через статически типизированный запрос.
Просто абсолютный ноль рефлексии у чуваков.
Forwarded from Ororo
людям обычно больше 5 модулей поднимать не надо