Check Levi9 best QA positions to Backbase team!
×Закрыть

Как понять, что ты программист?

Вот уже долгое время задаюсь вопросом, как понять, что ты программист? Я уже 3 года, как работаю C# разработчиком, довольно много повидал в жизни, но если меня, например, попросят написать программу вывода в консоль массива в обратном порядке или преобразовать String в int, то я наверняка зафейлюсь, потому что мне это особо в работе и не надо, а если будет надо, я зайду в гугл и найду решение. Зато я довольно быстро могу написать бекенд методы контроллера, создать связь с бд, продумать нетривиальную логику веб-приложения и т.д.

Так вот, могу ли я себя считать в таком случае настоящим программистом?

П.С. В теории я знаю ответы на вышеуказанные вопросы про массив и преобразование

👍НравитсяПонравилось0
В избранноеВ избранном0
LinkedIn

Лучшие комментарии пропустить

Ты программист с того момента, когда понял что за**авшая тебя бага где угодно оказывается написана в коде. Если ты полез править код — ты программист. Если нарыл способ обойти багу (и рассказать косоруким юзерам как надо настраивать) — ты админ. Если ты программист, но тебе банально надоело писать чужой говнокод, то есть все шансы выродиться в админа и спокойно уйти на пенсию, продолжая админить.

Могу заметить, что по мере роста количества [говно]кода и [говно]кодеров, количество обслуживающего персонала имеет склонность постоянно расти, и без него всё это разумеется дохнет. Так что подумай про это стезю, она достаточно широкая. ИЧСХ, тогда не надо постоянно зубрить все новинки, но надо хорошо знать то что УЖЕ ПРОВЕРЕНО, ПРИЖИЛОСЬ.

или преобразовать String в int

А думаешь, мы знаем? Зачем изобретать велосипед, если есть parseInt(), равно как и 0×18894 других мелочей которые давно сделаны для нас.

Массив в обратном порядке сортировать — за 15+ лет программирования пришлось ни разу. Но если придётся, в чем проблема? Тут гораздо сложнее если ты выбрал не тот язык, и тогда проблема не в отсортировать, а в том что кое-где ДЕБИЛЫБЛЯ решили что массивы и ассоциативные массивы (читай карты) — одно и то же. В смысле, обычных правильных массивов нет как таковых, и теперь хер поймёшь без поллитра где и когда вылезет у кобылы хъвост.

PS. А таких «настоящих» программистов, которые всё знают — просто нет. Нет даже таких, которые знают на 90%. И даже на 0.90%. И если бы кто посмотрел мою историю поиска, то не взял бы даже на курсы, типа «как можно этого не знать». Но я программист, с 15-летним стажем, и вместо того чтобы думать «а программист ли я», тупо беру и делаю. Матюкаюсь правда много. Не вслух, конечно, но комменты альфа-версий слабонервным лучше не читать, особенно если это когда-то был чужой код (например слизанный с гитхаба древнего проекта).

Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

Если ты одержим программированием, тратишь на него все свободное время, задрачиваешь тупые задачки и вопросы собеседований с искренним интересом и тебе не нужны деньги за все дополнительные активности, то ты программист.

і не просто програміст, а програміст-задрот

Если в один прекрасный момент ты вдруг обнаружил себя пялящимся в кучи букв на мониторе, которые нифига не складываются в адекватные слова, но ты улавливаешь в них какокй-то сакральный смысл и даже пытаешься там что-то исправить или улучшить;
если твое окружение и интересы ограничены такими же очкастыми задротами и новыми способами поправить тот самыйы код, и если за это тебе еще даже кто-то платит, то можешь считать себя программистом.

Зато понять, кто не программист, сравнительно легко. Кто 8 ферзей расставить не может — все, не программист. )

Или конем доску обойти. Или обойти конем доску, не попадая в клетки где стоят 8 ферзей)) Кстати, интересно возможно такое вообще или нет.

Щас LINQ делает нынешнее поколение C#-программистов ленивыми аки жирные коты. Люди, писавшие что-то до него, с массивами через циклы как правило работают с закрытыми глазами. Да и c pure JS иногда приходится как-то так повозиться.

Программист — это тот, кто пишет программы и получает за это деньги. Если оба эти условия для тебя выполняются, то ты — программист. Все остальное — рефлексия и субъективизм. Ты можешь быть плохим или хорошим программистом, но «плохой» и «хороший» — это субъективные понятия, которые определяешь только ты сам для себя. Определи их, ответь себе на вопрос, почему ты эти понятия определил именно так, составь план, как достичь того, чего тебе не хватает до того, чтобы соответствовать определению «хороший» и следуй ему. И поменьше слушай субъективные мнения других.

Пример: хороший программист — это программист, который может пройти собеседование в гугл/амазон. План: github.com/...​ding-interview-university

Никак. Для начала проспаться надо ;) - потом попустит...

я уже лет 10 пытаюсь понять
пока растет бабло можно делать вид что програмист. но и духовных практиках забывать не стоит. а то мало ли апокалипсис а ты ж програмист

нетривиальную логику ты тоже гуглишь на стаковерфлоу?

Мне видится ваша проблема в ложных ожиданиях. Просто в реалиях Украины после 3 лет «работы с языком С#» ожидание и программистов самих от себя, и эйчаров — что ты уже если и не синьор-помидор, то как минимум «крепкий мидл +», а на самом деле, в большинстве случаев такие люди еще по сути джуны, исключения на моей памяти были только среди тех, кто реально хорошо программировал еще до того, как устроился на первую работу.
Пишите больше кода, читайте, учитесь, делайте самостоятельно проекты. Написать «нетривиальную бизнес-логику» в чужом проекте это одно, сделать полностью самостоятельно хорошее, работающее приложение или сайт — совсем другое.

Які програмісти? Ви їх коли-небудь бачили? Ви ще бронтозаврів би згадали! Хyйня це все! Казки дідуся Панаса, не було ніяких програмістів.

Нет, не можешь, если:

Я уже 3 года, как работаю C# разработчиком

— это и весь твой опыт в программировании. Это всё равно, что назвать меня лингвистом, если я владею одним русским языком.

или преобразовать String в int, то я наверняка зафейлюсь

Ты можешь не помнить как сконвертить 5678 в hex, но если пишешь на языке, то хотя бы её азбукой надо владеть без гуглов.

продумать нетривиальную логику веб-приложения

вот логику, пожалуйста, не надо. Логика приложения должна быть проста, как грабли. На любом уровне её сложности.

Я тут подумал... Если тебя раздражают часовые митинги, ты уже на шаг ближе к тому, чтобы чувствовать себя тру-программистом Ж)

А если никого не убил [за последние полгода 5 месяцев и 6 дней] на этих митингах?

Не получается. Все девы засыпают ещё до тревожного звоночка.

Тебя просят починить кондиционер, пылесос или принтер? Если да, то ты ж программист.

именно поэтому ты себе лейбочку Senior поставил?

Очень плохой йумар

поменять картридж в ксероксе , прокинуть проводку, поправить баланс в 1С чтобы сходился, и множество других нужных дел

попросят написать программу вывода в консоль массива в обратном порядке или преобразовать String в int

після трьох років роботи це виглядає тролінгом

Программистов не бывает. Есть люди, которым кажется, то они программисты, а есть люди, которым не кажется, что они программисты. Вторые задают вопросы первым, и потом, вторым уже не кажется, что первые программисты, а кажется, что первые тоже не программисты, но им, что есть правда, кажется, что они, первые, программисты.
Так что живи спокойно! )))

...Потому что это же Программист! А тот, который он, это он, он тоже программист, невчёный, но... зачем же?! Это ж ведь очень и очень! Да! Да! Но нет!

Смотря что вы имеете в виду под понятием программист? Например, не знание сортировки списка в обратном порядке говорит о том, что у вас:

* отсутствуют базовые знания программирования (какие типы сортировки в знаете?)
* слабые знания и малый опыт использования стандартных коллекций дотнета, т.е. вы не знаете:
— что в классе List есть методы Sort(Comparison) и Sort(IComparer)
— предположительно вы не знаете назначение компонентов Comparison и IComparer

Вопрос, а надо ли это знать и оно когда-нибудь применяется, как бы подразумевает, что опыта у вас действительно мало.

Работаю около 9 лет, из них большую часть работал с php. Но параметров функции array_reverse без документации не вспомню. Даже не уверен что она так называется. Аналогично с array_sort (сортировать в mysql запросе эффективнее когда речь о больших наборах данных и необходимости отсортировать, а затем получить часть; поэтому как раз order by я помню, но это специфика задач над которыми нужно было работать мне). И не понимаю почему редко используемые знания кто-то может считать базовыми и такими, которые необходимо постоянно держать в голове.

Но параметров функции array_reverse без документации не вспомню.

Но вы же помните, что в документации есть функция array_reverse. И вы не не начнете гуглить и искать готовое решение на стэковерфлоу и т.п. а откроете документацию

сортировать в mysql запросе эффективнее когда речь о больших наборах данных и необходимости отсортировать

а если небольшой набор данных из файла или веб-сервиса? Для сортировки вы его сначала сохраните в таблице а потом сделаете выборку?

и да

Работаю около 9 лет

это еще ни о чем не говорит

То есть ты бы мне ради чтения 50 строчек из файла наплодил бы кучу реализаций айкомпэрэров в иде?

А ты бы создал временную таблицу в бд и сделал отсортированную выборку?

айкомпэрэров

И как я понимаю, ты не в курсе, чем отличается Comparison и IComparer и что такое лямбды?

а если небольшой набор данных из файла или веб-сервиса?

Открою документацию и посмотрю какие для этого существуют инструменты. Зачем мне знать их на память?

это еще ни о чем не говорит

Да? Ок.

Открою документацию и посмотрю какие для этого существуют инструменты. Зачем мне знать их на память?

Ну вот, вы в свое время изучали этот вопрос и помните, что сортировка реализована на вашей платформе. Поэтому быстро освежите свою память, в отличии от гугла. А если нужно будет вдруг реализовать сортировку на другой платформе, которая не содержит стандартную реализации (кроме ассемблера, я не знаю такой), то помня хотя бы названия алгоритмов вы очень быстро найдете описание и так же быстро реализуете его.

Т.е. знание хотя бы базовых стандартных компонентов платформы и обзор хотя бы простых алгоритмов (которые препадают в школе) для программиста обязательно

Во первых, это не функция языка, а компоненты стандартной библиотеки/фреймворка. А во вторых не обязательно помнить и знать все алгоритмы. Задача то как стояла:

написать программу вывода в консоль массива в обратном порядке

Берем стандартные компоненты и пишем тривиальный код, грубо говоря, в одну строчку.

ТС, вероятно, имел ввиду -САМОМУ написать программу сортировки массива в обратном порядке, а не просто вызвать готовый компонент..

Он же четко описал

написать программу вывода в консоль массива в обратном порядке

Вполне возможно, что авторы задачи предполагали, что при реализации будет использоваться cocktail shaker sort алгоритм. А может быть они думали, что будет изобретен новый алгоритм . С таким подходом надо менять профессию на гадалку.

И не понимаю почему редко используемые знания кто-то может считать базовыми и такими, которые необходимо постоянно держать в голове.

Если вы с вашим 9-ним опытом не сталкивались с этими задачами, то это не значит, что это «редко используемые знания».

У нас тут есть на форуме Виктор из Беларуси, он как придет расскажет что всем нужна высшая математика, ряды, и что там ещё используется для распознавания образов.

Не расскажу, ибо не нужно всем ну совсем. Нужно только тем, кто в эти области нос сует.
Для программирования школьной математики выше крыши, проблема, что многие программисты даже этого не знают.

Ну, если для знания базовых компонентов и простых алгоритмов (по сути — школьных) — необходимо знание высшей математики, то ok, подождем экспертное мнение Виктора :)

Это для каких базовых компонентов в программировании нужна высшая математика?

Для понимания как работает квиксорт тебе ну совсем не нужно знать в деталях графы.
И более того не существует в мире людей, что даже всю базы высшей математики университетского курса идеально знают. Каждый знает только в части своей области применения — мозг человека не тянет такой объем знаний держать в «быстрой» памяти. Обычно, за чем отличающимся от привычного и постоянно используемого лезут в учебники и справочники, сейчас гугл.

В универе это преподают несколько лет. В школе нет.
Но если меня сейчас спросить про кольца и подобное, ничего не вспомню, хотя в свое время, будучи студентом понимал и знал на отлично. Это ни разу мне не понадобилось в жизни. А вот матричная арифметика постоянно. Но и ее давно уже не надо писать самому, есть куча оптимизированных под железо либ и инструментов.
Но, та же матричная арифметика нужна в очень узком наборе задач, программистам она обычно не нужна, иногда заюзать класс, что предоставляет матрицы по мануалу с гугла.

Это избыточно (я про Comparison и IComparer). Если требуется «отсортировать в обратном порядке», то это чистый троллинг. Поскольку задача предполагает наличие уже отсортированного массива, и все, что нужно сделать — выделить столько же памяти и пройтись один раз задом наперед. Что с успехом делает IEnumerable.Reverse (возможно, не самым-пресамым оптимальным способом).
Про StrToInt, думаю, тоже троллинг, потому что val[i]-’0′ - на это три года не нужно.

если не сказано что сортированный, то обратная сортировка отличается от прямой , только компаратором работающим в обратную сторону

а вообще было написано «вывести в обратном порядке». это даже не сортировка. это просто итератор с конца в начало

Выпей бутылку-две пИва на чесно заработанное программированием бабло, и положительный ответ придет сам собой :8)

Як зрозуміти? А просто — лячкаєш говнокод мегабайтами цілодобово. Вчишся новому. Є один, або декілька петпроектів.

Выражение есть такое:
«Люди разные нужны, люди разные важны»

А какая разница? Работаешь, деньги платят — и норм. Я вообще как-то читал маразматическую статью для менеджеров, где утверждалось что важно, называет ли себя кандидат programmer или developer. И типа кто-то из них круче другого.

ну инж и дев это с образованием или без, в этой стране не важно, а в какой-нибудь другой это «программист, есть во» и «программист, нет во»

а если будет надо, я зайду в гугл и найду решение

Обожаю такое — знания «в кредит». Раз я всегда могу нагуглить, то, вроде как, можно считать, что я это знаю. Проблемка возникает в тот момент, когда надо

продумать нетривиальную логику веб-приложения

а ты такой не понимаешь, что гуглить. Потому что думать получается только тем, что ты уже прочитал, а не тем, что можешь еслишо нагуглить.

А по-вашему нужно знать свою область на память и не соваться никуда, потому что не знаешь? Разработка в 2017 работает не так. Всё знать и запомнить невозможно, поэтому стоит иметь только общее представление, а детали гуглить. Автор имеет представление что отсортировать массив в обратном порядке можно. Этого достаточно чтобы в нужный момент вбить в гугл `${language_name} array reverse`.

Странно, что вообще все еще существует специализация программистов, когда можно же иметь только общее представление. Когда гугл на собеседовании начнет спрашивать не знания, а навык гугления — можно будет заикнуться о том, как работает разработка в 2017.

Где вы, я, мы все и где гугл? И какая связь между собеседованием и работой в средней конторе?

что вообще все еще существует специализация программистов, когда можно же иметь только общее представление

Программисты это общее представление имеют, не-программисты нет. Поэтому специализация и существует. А считать что кто-то должен знать на память вещи, которыми не пользуется — прошлый век.

А считать что кто-то должен знать на память вещи, которыми не пользуется — прошлый век.

Вся драма в том, что часто под вроде бы резонным вопросом «зачем запоминать вещи, которыми я не пользуюсь?» скрывается очевидное «я ведь пользуюсь только тем, что знаю, что запомнил когда-то». Курица и яйцо, компрене ву?

Вся драма в голове. Уж не знаю почему вам хочется так думать, как вы думаете.

Проблемка возникает когда нужно ДОВЕРИТЬСЯ этим знаниям, и нет никакой возможности их проверить.

Пример: для инсталляции одной популярной программы нужно станцевать с бубном и провести ряд линуксовых консольных команд. Проблема в том, что одна из них на популярном дистрибутиве (под который кстати заявлена эта инструкция) напрочь убивает сеть заменой дефолтного пакета, то есть сервер ложится полностью и к нему более не подключиться.

Гадость в том, что САМИ АВТОРЫ софтины не постеснялись просто отбрехаться по проблеме, типа «да это же очевидно». Но это очевидно только тем, кто УЖЕ нашёл ветку форума, где они общаются на правах младших богов. И найти её можно только по описанию ОШИБКИ.

Или вот из Мелкомягкого стека любимый метод «решения» проблем обновления — выдать целой системной папке неограниченные права на запись, или ветке реестра. Вместо того чтобы поправить свой же патч, которому прав не хватает. Думаешь, это редкая проблема? Не для тех, кто обновлял первые версии Windows 10. Кстати, по сей день не существует решения, как заставить эту суку обновиться ПРИНУДИТЕЛЬНО, без «буду — не буду», написав ошибки в лог, вместо того чтобы требовать переустановки всей системы с нуля.

Тобто ? Потрібно якийсь апдейт поставити — зкачуєте звідси www.catalog.update.microsoft.com потрібний msu чи cab, і запускаєте DISM /Add-Package з /IgnoreCheck. На свій страх і ризик.
Якщо ж про варіант з апдейтом W10, скажімо, 10.0.10240 build до більш нового, коли в процесі апдейта виникає помилка і йде роллбек назад на старий білд, то так, тут проблемка — заборонити роллбек при помилці не вийде.
Але лог там пишеться (docs.microsoft.com/...​windows-10-upgrade-errors), можна побачити, в чому проблема. Якщо драйвери, іноді допомагає варіант взяти потрібні драйвери, засунути в дистрибутив (скажімо, за допомогою NTLite), потім апдейтити систему.

Якомусь файлу, незрозуміло якому, із тем оформлення, не вистачило прав доступу. ЯКІ САМЕ ПОТРІБНІ і якому юзеру — звичайно не пише.
При тому теми оформлення стандартні, якщо їх просто знести — не виходить.
Намагався дати права усім — не допомогло, воно перевіряє права за конкретним шаблоном, не збігається — ось тобі роллбек всієї системи без пояснень замість того щоб ПРИМУСОВО їх встановити.

Може називатись лікарем лише той хто: зможе провести самотужки коронарне шунтування, трансплантацію печінки, імплантацію хоча б 29 із 32 зубів.
Може називатись будівельником лише той хто: здатен спроектувати і побудувати багатоповерхівку на березі річки з глиняним ґрунтом, має досвід керування краном, бульдозером, екскаватором, відбійним молотком; в змозі добудувати храм святого сімейства в Барселоні.
і т.д.

P.S.

Зато я довольно быстро могу написать бекенд методы контроллера, создать связь с бд, продумать нетривиальную логику веб-приложения и т.д.

Ви це можете, тому що ви це вже робили, вам просто необхідно буде повторити свої кроки з незначними змінами.
P.P.S

программу вывода в консоль массива в обратном порядке

Вибачте, але це елементарщина яку повинні вміти всі, хто хоча б трохи програмує, подібні навики на рівні загальної грамотності.
Трохи інша справа із задачами а-ля

преобразовать String в int

В цьому випадку, ви маєте знати, як засобами С# виконати таке перетворення, знати, як це робити на низькому рівні це круто, але не особливо потрібно.

Особисто я б назвав програмістом того, хто вміє вирішувати поставлені перед ним завдання і писати ± чистий код.

Може називатись лікарем лише той хто: зможе провести самотужки коронарне шунтування, трансплантацію печінки, імплантацію хоча б 29 із 32 зубів.

Почитайте про те як готують лікарів в США.

они себе зубы лечат?

Лікарі там вузькоспеціалізовані: жартують, що один лікує ліву ноздрю, а інший — праву, а не як у нас вухо-горло-ніс.

В цьому випадку, ви маєте знати, як засобами С# виконати таке перетворення, знати, як це робити на низькому рівні це круто, але не особливо потрібно.

10 років не програмував але рішення банальне — в циклі задом наперед берете символ зі string, перевіряєте що це цифра (якщо ні — викидаєте exception) множите на степінь 10 і додаєте до результату. Банальщина.

Ну ви молодець, якщо можете це зробити, але я мав на увазі, що C# девелопер, перш за все, повинен знати, що можна зробити так:
int x = Int32.Parse(Text);
А вже потім городити костилі із циклів.

Це не костиль з циклу — скоріше всього воно так і було реалізовано.
свого часу в ТП і Делфі ВСІ бібліотеки нижнього рівня (де як раз і були реалізовані всі ці StrtToInt були доступні в source code. І читати їх було дуе корисно для розуміння що ж там під капотом.

Я знаю, что ничего не знаю © Сократ.
Я уверен, что 95% резвящихся здесь троллей не смогут и байта из регистра в регистр переслать без использования GC. В качестве доказательства рекомендую интересующимся пройти в топик про TopTal и запротоколировать боль, унижение и анальные слезы людей, которые таки (по собственным утверждениям) могут сортировать в обратном порядке списки в консоли (на самом деле — нет).

байта из регистра в регистр переслать без использования GC

mov eax, ecx

Orly? Любой у которого ассемблер был в универе сможет.

Как сказал один попутчик быдло-араб, если не умеешь взламывать Пентагон, то ты не программист

если не умеешь взламывать Пентагон,

причем взламывать через калькулятор

продумать нетривиальную логику веб-приложения

В голосину

И услышать всё, что думают реальные пользователи о нетривиальной логике, и её нетривиальном авторе.

мне это напоминает ситуацию когда нужно составить регулярное выражения и приходится лезть в гугл, потому что забыл всё напрочь

приходится лезть в гугл

И там натыкаешься на отрезвляющий пост о жидкой боли текущей из глаз и сразу попускает)

Смеёшься? Регулярные выражения сами по себе настолько МУДАЧЕСКАЯ технология, отрицающая все принципы высокоуровневого программирования, что даже ассемблер — красота неописуемая по сравнению с этой «магией».

Разумеется, эта «магия» работает везде по-разному. Имеет несколько официальных нотаций, и до женского полового органа недокументированных реализаций.

Особо выдающимся особям, считающим что регулярные выражения нужно вынести в настройки КОНЕЧНОМУ ПОЛЬЗОВАТЕЛЮ, и не дать никакого другого способа настроить — надо отпиливать ййца ржавыми садовыми ножницами: безуспешно, но регулярно.

Задача для тех, кто считает иначе: [можете лезть в Гугл и справочник чёрной магии]
Есть строка. Возможно с краказяблами и UTF8, включая 6-байтные символы. Находится в переменной.
Есть настройка или параметр функции, принимающий на вход эту самую регулярку. Реализация неизвестна.
Нужно пропихнуть строку, то есть преобразовать в регулярку, так, чтобы на выходе она осталась той строкой, что была на входе, не будучи покоцаной парсером.
Прошу публику дать только правильное решение, с первой попытки. Будет неправильное — смотрим предыдущий абзац. То что решение не ваше — не волнует, ответственность в реальных проектах будет вашей.

Регулярки — это же интрумент для своих задач, как и все остальные. Если в одном месте его неправильно использовали — это не значит, что инструмент плохой.

Ядерная бомба — тоже. Но просто представь себе ситуацию, что команда на запуск ядерной бомбы работате на регулярках!

Так не применяй регулярки для запуска :)

И да, пагаварить всякий может. Ты задачу-то решил? Простейшая ведь!
На входе автор вместо параметра строки поставил регулярку — для вашего удобства.
Каким образом ГАРАНТИРОВАННО скормить ему нужную строку со всем диапазоном символов, чтобы она после прохождения парсера стала исходной строкой?

И мысли не было заниматься этой задачей. Опять же, для каждой задачи свой интструмент. Регулярка не справляется или ты ее не понимаешь — поменяй предусловие. Пиши юнит тесты.

Во-во. Отличный метод программировать, когда результат надо УГАДЫВАТЬ по юнит-тестам. ЗБС читаемость кода!

А тяжёлая задача, наверное, строку скопировать из пункта А в пункт Б?
ИЧСХ, задача-то практическая, из реального мира.

результат надо УГАДЫВАТЬ по юнит-тестам

Не надо результат угадывать по юнит-тестам — тесты лучший способ документирования кода, особенно непонятного так как комментариии устаревают. Но это уже другая тема, на которую у вас противоположное мнение — помню из других дискуссий.

Ваша боль по по поводу юникода в Java мне непонятна так как с C# все, с чем сталкивался работал как ожидалось. Но если не работает — покройте тестами и перепишите, если есть така возможность. Я бы так поступил в подобной ситуции исходя из доступной инфы.

Хороший ответ, при том что ожидают решение в одну строчку, а вообще пользователь ждёт без неё.

Приходим к мысли, что RegExp имеет СТРОГО ОГРАНИЧЕННУЮ область применения, и там где со стороны пользователя или внешнего источника ожидается ввод регулярного выражения — нужно делать ОТДЕЛЬНУЮ ДЫРКУ для ввода обычной строки.

Иначе весь геморой изучения RegExp (и понимания беспросветного идиотизма этого подхода) — ложится на конечного пользователя. Потому как программисты, во всю глотку кричащие как это хорошо — не способны решить простейшей задачи передачи строки, притом ни один. И требуют от пользователя и внешних источников «правильных» данных, а какие правильные — понимать через телепатию.

Крик души у вас прям. Нужен regex от пользователя для валидации каких-то данных сделайте конструктор чтобы пользователь выбрал что конкретно он хочет проверять. Странный какой-то UX завтавлять пользователя самому вводить регулярку, при том, что девы кричат во все горло и не умеют решать простых задач. Кто их у вас набирает?

Ладно, за сим откланиваюсь ;)

Дык не у нас! У нас как раз UI хороший, годный, документированный. Но вот там где мы вынуждены пользовать чужие API, и пропускать туда данные пользователя через универасльный интерфейс...

Это не крик души, а лишь констатация факта что RegExp есть геморой по определению, что он противоречит читабельности кода, и везде где только можно требуется от него уходить. А там где нельзя — документировать каждый чих, чтобы читающий понимал что вообще он делает (вернее хотелось чтобы делал).

документировать каждый чих, чтобы читающий понимал что вообще он делает (вернее хотелось чтобы делал)

Соглашусь с этим для нетривиальных выражений.

регуляркой можно по быстрому распарсить цвет в формате hex, или проверить что это он (парсить в этом случае можно и обычным сплитом строки), можно проверит что это UUID, на крайняк что это телефон или почтовый код в конкретно взятой стране. регуляркой можно проверить что нема запрещенных символов в строке — к примеру знак вопроса, хеш, или точка. когда есть юникод — не хер юзать регулярки. так же не хер юзать регулряки для проверки имен — вот это самое зло пожалуй, и другого натурального текста

можно чтото большее сделать, но лучше не надо.

когда есть юникод — не хер юзать регулярки

пачиму?

допустим мы хотим проверить адрес что это адрес. в Java имплементации есть хороший спец. знак \L который означает любую букву во всех языках, пока вы юзаете Java — все ок, но вот другие реализации уже не такие хорошие, и теперь вопрос — вы знаете диапазоны всех букв, во всех алфавитах? плюс не стоит забывать что некоторые китайские символы являются составными — и с вероятностью в 99% какието буквы ваша регулярка не пропустить, и будете добавлять вручную потом диапазоны, ибо Аладин из Саудавской Аравии и Сунь из Китая не смогли купить нужный им товар/зарегатся в системе.

кончено если вы должны проверять не натуральный текст, а просто тех информацию то в целом можно попробовать

ааа, вон о чем речь.
\w вон ваще только с латиницей работает стабильно.
но тут уже встречный вопрос: зачем вообще анализировать смысловую часть с помощью регулярки?

это как проверять валидность email адреса — положим, сделал офигенную регулярку согласно RFC. а почтовый сервер целевого домена не позволяет экранированные кавычки в адресе использовать. или еще круче — адрес по формату валидный, но не зарегистрирован.

с другой стороны, разбивка на токены по \s вполне себе будет работать, вне зависимости от реализации.
или вытянуть из длинной строки нечто конкретное — тоже не проблема, хоть юникод, хоть нет.

\w вон ваще только с латиницей работает стабильно.

и для тех. информации прокатывает

но тут уже встречный вопрос: зачем вообще анализировать смысловую часть с помощью регулярки?

некоторые пытаются вытянуть название улицы, райцентра

с другой стороны, разбивка на токены по \s вполне себе будет работать

ведь это же не юникод ))

некоторые пытаются вытянуть название улицы, райцентра

это проблема гораздо глубже вопроса работы \L
в разных странах разное административное деление
плюс сокращения("Днепр. обл.«)
плюс необязательность разделителей
плюс «полное» и «не полное» название, типа «ул. Либкхнехта», «К. Либкхнехта», «улица Карла Либкхнехта» и ваще уже «ул. им. Карла Либкхнехта»
плюс опечатки и грамматические ошибки
конкретно эта иллюстрация — она про боль, не связанную с регулярками

это было первое что пришло в голову )))

Гораздо круче, если они СМОГЛИ купить нужный товар, и прописать себе бесплатную экспресс-доставку через полмира на пятицентовом товаре.

По-быстрому — да. Но во-первых, где гарантия что правильно? А во-вторых, когда встретишь этот текст в чужом коде, ты быстро поймёшь что он ДЕЛАЕТ, и что НУЖНО чтобы он делал?

И это всего лишь парсинг 6 букв. А что уж говорить от том, когда надо жёсткие файрволы на них конфигурировать, с гарантией что никакая ДРУГАЯ регулярка не обманет эту? ИЧСХ, другой возможности сконфигить просто нет.

ИЧСХ, если логика написана в коде — то в случае опечатки вероятнее всего не скомпилится, или выкинет ошибку. А вот регулярка с опечатками может «успешно» работать месяцами, пока жопа в данных не вскроется.

Ты что??? Без знания генетических алгоритмов и решения диффуров высших порядков ты code monkey :)) А еще при приему на работу, каждый фронтент разработчик должен рассказывать как устроены нейронные сети внутри

Ожидаемо, саркастично начали бросаться в крайности. Действительно, все из вышеуказанного нет необходимости учить, и это не будут утверждать даже сторонники концепции «образованного программиста» (взамен они достаточно справедливо найдут десяток других вещей, которые знать не помешает). Исключение — только если интересно или работа на этом завязана.

Но топик-стартер ведь говорит о совершенно базовом алгоритмическом мышлении и/или понимании встроенных структур. Такие вещи знать необходимо, поскольку потребность в них в итоге возникает и в работе тех, кто «пишет формы». И незнание подобного — большой недочет, снижающий эффективность работы. Хотя в случае тс-а, удивительно, имело право на жизнь на протяжении 3 лет.

Следовать подходу «выучу, если понадобится» — неплохо, но не в случае, когда речь идёт о совсем фундаментальных вещах.

А на галере что-то другое нужно?

Ты программист с того момента, когда понял что за**авшая тебя бага где угодно оказывается написана в коде. Если ты полез править код — ты программист. Если нарыл способ обойти багу (и рассказать косоруким юзерам как надо настраивать) — ты админ. Если ты программист, но тебе банально надоело писать чужой говнокод, то есть все шансы выродиться в админа и спокойно уйти на пенсию, продолжая админить.

Могу заметить, что по мере роста количества [говно]кода и [говно]кодеров, количество обслуживающего персонала имеет склонность постоянно расти, и без него всё это разумеется дохнет. Так что подумай про это стезю, она достаточно широкая. ИЧСХ, тогда не надо постоянно зубрить все новинки, но надо хорошо знать то что УЖЕ ПРОВЕРЕНО, ПРИЖИЛОСЬ.

или преобразовать String в int

А думаешь, мы знаем? Зачем изобретать велосипед, если есть parseInt(), равно как и 0×18894 других мелочей которые давно сделаны для нас.

Массив в обратном порядке сортировать — за 15+ лет программирования пришлось ни разу. Но если придётся, в чем проблема? Тут гораздо сложнее если ты выбрал не тот язык, и тогда проблема не в отсортировать, а в том что кое-где ДЕБИЛЫБЛЯ решили что массивы и ассоциативные массивы (читай карты) — одно и то же. В смысле, обычных правильных массивов нет как таковых, и теперь хер поймёшь без поллитра где и когда вылезет у кобылы хъвост.

PS. А таких «настоящих» программистов, которые всё знают — просто нет. Нет даже таких, которые знают на 90%. И даже на 0.90%. И если бы кто посмотрел мою историю поиска, то не взял бы даже на курсы, типа «как можно этого не знать». Но я программист, с 15-летним стажем, и вместо того чтобы думать «а программист ли я», тупо беру и делаю. Матюкаюсь правда много. Не вслух, конечно, но комменты альфа-версий слабонервным лучше не читать, особенно если это когда-то был чужой код (например слизанный с гитхаба древнего проекта).

Чтобы понять, что ты программист, тебя должен вначале укусить радиоактивный программист. Сначала пальцы покроются волосами, из рук будет стрелять байткод и ты будешь липнуть к стенам из-за клейкого смузи, который будет выделяться из тела

Осторожно спрошу: ты программист?

Кстати а что по твоему нетривиальная бекенд логика?

хах, таке ж саме питання :)

может, когда смотришь в неё и сам не понимаешь, что здесь происходит?

Ну некоторые и не понимают как работаеи left join, но это вроде как тривиальная вещь

Некоторые (в моём лице) не понимают как (вернее зачем) работают остальные джойны, кроме INNER JOIN (он же просто WHERE condition) который фильтрует обе таблицы, и LEFT JOIN, который фильтрует только вторую.

Единственный случай разумного применения RIGHT JOIN — это когда естественный язык автора пишется справа налево.

ну FULL OUTER JOIN может еще в теории пригодится для построение матриц (редкость), но дело в тех кто не понимает как работает join — и как на него влияют индексы

FULL OUTER JOIN может еще в теории пригодится

Вот именно что В ТЕОРИИ. А на практике — это женская логика.

Про индексы — давай, расскажи как в Sybase или MS SQL они работают. Когда в запросе явно задан поиск по ключу, а эта сволочь избирает ДРУГИЕ параметры (например индекс по дате) и... не пользуется индексом, потому что в запросе BETWEEN, IN, или ещё какая логика.

И тут мы пришли к тому что надо уметь профилировать запросы, и давание подсказок какой индекс юзать

И тут мы пришли к тому, что надо уйти от SQL и перейти к конкретным костылям под конкретную базу. Которые просто ахудивительно портируются под Hibernate и ему подобные универсальные надстройки.

а потом удивлятся почему копиранивоние 500 строк занимает около 5 минут.... :)

Ну так чудес не буває — або/або.
Жертвуємо швидкістю заради універсальності.
Якщо оптимізатор вирішить, що фуллскан буде швидший за пошук по ключу — пошуку по ключу не буде.

Але ж не в десятки тисяч разів! В моєму варіанті пожертвували Sybase і поставили Percona (форк MySQL). Там звичайно свої грабельки (чи краще казати хотєлки яких нема), але ж не такий гємор коли йде позаіндексний перебор!

RIGHT JION нужен для красоты и симметричности, а так же для облегчения трансляторов из какого либо DSL в SQL.

выражается в огромном колличестве правил, как связанных с собой так и независимых но с разветвленными кейсам

стейт машина — и все правила становятся простыми

— необходимость поддерживать несколько часовых поясов и связывать их вместе при расчетах

unix time наше все — и боли поясов больше нет

— агрегация на разных уровнях иерархиии и увязка цифр, особенно когда это не дерево а бидирекшнал граф

тут явно чтото пошло не так, какие агрегации для бидерекшинал графа? для дерева — ок, но я бы решил через события, вроде как ниче военного

поддержка исторических состояний то что называется ’as of’, в купе с кучей мелких рулов это превращается в ад

старая аксиома — закрыто к изменению — открыто к расширению, и у исторический состояния будут сами собой

хотя вот эти «исторические состояния» — это просто баги которые были приняты как фичи

стейт машина — и все правила становятся простыми

тут о композиции речь. десяток простых взаимно-не-исключающих правил — и бум, у тебя 1024 стейта? думаю, нет. значит, надо будет анализировать, выбрасывая невозможные комбинации, а остальные таки разделять на независимые «слои»

unix time наше все — и боли поясов больше нет

пока не захочешь померять время между событиями("напомнить мне за два часа"), показать одновременность("показать всё в моем календаре")

пока не захочешь померять время между событиями("напомнить мне за два часа")

за два часа — оно во всем мире за два часа, без привязки к времени

показать одновременность("показать всё в моем календаре")

в моем календаре мое время — то есть одно

вообще проблема со временем то что многие хотят в модель зашить представление данных — что понятно если человек не знает как массиву реверсе сделать.

тут о композиции речь. десяток простых взаимно-не-исключающих правил — и бум, у тебя 1024 стейта?

композиция стейтов — решается через композицию функций — функции высшего порядка в таких вопросах помогают

за два часа — оно во всем мире за два часа, без привязки к времени
unix time наше все — и боли поясов больше нет

Ну не все так просто.
Например, есть некие временные ряды, хранить нужно вместе с таймзоной происхождения/измерения. Расчеты привязываются к таймзоне, но в определенных случаях важна таймзона клиента, или в случае если происходят некие арифметические операции с группами рядов, здесь уже важна таймзона обоих рядов, надо которыми совершаются операции. Сложности добавляют переходы на зимнее/летнее время.
Если еще и добавить разные требования представления данных (для разных клиентов), то стройная модель поначалу начинает рушиться уже на этапе моделирования данных. Ну а если смотреть в конкретные реализации, то голова начинает понемногу пухнуть, а ведь нужно поддерживать всё уже написанное)

хранить нужно вместе с таймзоной происхождения

если вы хотите то можете так хранить, но работать надо всегда с юникстаймом

Расчеты привязываются к таймзоне

вот это и есть ваша ошибка, ее совершают почти все.

таймзона — это представление, время всегда одно, потому если считаешь к юникс тайм все прекрасно,но всегда найдется ктото кто скажет а давайте вместо юникстайма вернем время в виде строки — и сразу же появляются проблемы. информацию о таймзоне можно использовать конечно для определенных случаев.

вообщем это типичная ошибка большинства программистов которые рассказуют что базу знать не надо. сами проблему создали, сами с ней боремся — классика

ктото кто скажет а давайте вместо юникстайма вернем время в виде строки

ага.
например, дату рождения вернуть как timestamp.
тогда, если отображать на клиентах в разных таймзонах — либо получим, либо не получим смещение на один день. Смотря, как таймзона клиента отличается от таймзоны, для которой тот юникстайм создали.
удобно, чё.

так ведь и не на всем шарике 31 июля

— сервер-сервер, а когда у Ани Днюха?
— а это зависит.
— от чего же?
— от твоей собственной таймзоны.
— ну, ок :(

— сервер-сервер, а когда у Ани Днюха?

— 20 июля UTC (только в секундах)
— а у меня еще 19 июля, у меня ей еще 17 — не буду в секцию для взрослых пускать

полетел в командировку, а у тебя напоминалки автоматически переместились.
удобно? не думаю.

Outlook, к примеру, может календарь показывать в разных часовых поясах

угу, в том случае надо организовать одновременность двух событий("начинается совещание" и «юзер подключается на это совещание»).
но День рождения(отметка «весь день») не съезжает же частично на предыдущий день? или съезжает?

событие на весь день привязывается к дефолтной таймзоне емнип
Хотя скайпы и фейсбуки ничем таким не заморачиваются, люди из Австралии начинают поздравлять еще вечером предыдущего дня

Вообщето удобно, ибо если вы хотели комуто позвонить в 15:00 то в другой стране вам надо звонить в 17:00

Давайте представим себе условное предприятие, которое потребляет электроэнергию. Тарифы на электроэнергию меняются в течение дня и ночи, потребление тоже меняется в зависимости от конкретного часа (есть статистические ряды). Теперь представим что у этого предприятия есть также куча ветряков, которые генерируют электроэнергию. Энергию можно или потребить, или продать. Продать ее нужно всю, поэтому энергию нужно выставить на продажу через специальный регулятор. Регулятор — это своего рода биржа. Предлагаемая цена продажи точно так же зависит от конкретного часа. Есть разные виды рядов в результате с разной грануляцией и с разными привязками к таймзоне. Баланс потребления и генерирования должен у предприятие сходиться к нулю по завершению «расчетного часа», есть суточные балансы и месячные. Это совершенно небольшая часть бизнес-модели, всю я все равно не знаю)
Продолжаете настаивать что

работать надо всегда с юникстаймом

?

Не совсем, дневной время это абстракция. Продажа я так понимаю зависит от времени продающего а не покупаещего?

Скорее всего, трейдинг — немного отдельная область со своими приложениями. Не очень понятно, какое это имеет значение.

суть в том, что если (а так обычно оно и есть) вы продаете время по одному часовому поясу, поясу продавца — то вам не нужна информация о часовой зоне — ибо в УТЦ будут диапазоны с разными ценами. в 95% часовоая зона делают вашу жизнь тяжелее, ибо вам надо подстраиватся — когда я говорю — юникс тайм — имею ввиду реализацию всех операций в одной таймзоне — и это почти все что всем надо. ибо если ваша фирма продает с 9 до 10 электричество по 5 долларав за кв, то даже если у покупателя это с 10 до 11 продавец все равно продает в том же времени. но многие начинают играть в таймзоны — из-за чего возникает боль, и усложнение на ровном месте — и добавление очередной абстракции, когда в реальности одну надо снять (помним что таймзона это абстракция над временем в контексте нашей планеты, и ее нахождение в солнечной системе) — таймзона обычна нужна когда предоставляем данные конечному пользователю — внутри системы, это абстракция не нужна

))
Не будем продолжать этот бессмысленный спор. Я только добавлю что одно время данные хранились в базе без таймзоны (таймзона хранилась отдельным числом), в результате требовалось гораздо больше операций. С добавлением таймзоны многие арифметические и «делительные» операции над временными рядами упростились, притом что реализовано все равно ужасно неоптимально, хотя и в базе.
Из других систем данные приходят со своими таймзонами, у регулятора свои требования и по представлению данных, и по наполнению.
А есть компании, у кого не просто электростанция или городское управление, у некоторых бизнес-подразделения в разных частях света и данные собираются (агрегируются) регулярно. Трейдинг у таких компаний идет 24/7. Для трейдинга вообще все просто, там диапазон задается временем открытия/закрытия рынка в местной таймзоне и интервал час-полчаса. Если интрадей, то диапазон и интервалы меньше. Для трейдинга хранение таймзоны не принципиально, тут нет какой-то арифметики, нужно только презентовать данные в правильном формате. Для расчетов это важно, так как нужно временные ряды потребления (или генерации) и тарифов приводить к «общему знаменателю», для арифметических операций, «деления», «умножения» это тоже может быть важно.

но в определенных случаях важна таймзона клиента

у меня проект, где тайм зона клиента настолько не важна. что лучше как со строками работать(грубо говоря, расписание в рамках физически одного и того же предприятия).

Стейты будут весьма просты. А юникс тайм все упростить — ибо отчеты нужны несколько раз в сутки по утц, и закрывать надо утц, а вот когда будете генерить пдфку тогда вспомните про таймзону токо для кого генерится, да и в целом это просто как два пальца обосать

Ні, не можеш.

если меня, например, попросят написать программу вывода в консоль массива в обратном порядке
то я наверняка зафейлюсь,

После этого у меня возникают сомнения в

Зато я довольно быстро могу написать бекенд методы контроллера, создать связь с бд, продумать нетривиальную логику веб-приложения и т.д.
а если будет надо, я зайду в гугл и найду решение.

Ну если с этим проблем нет, то и не надо париться. Все знать не возможно, да и не используемые знания имеют свойство забываться.
Хотя это ппц:

написать программу вывода в консоль массива в обратном порядке

Думаю за 3 года работы можно было заметить Reverse в экстеншенах и foreach тоже достаточно часто используется)

софтваре инжинир и не заморачивайся, остальные такие же, если хочешь эту область подтянуть есть www.hackerrank.com и подобные, там и теория и практика

просто у тебя не хватает некого бекграунда который учат в универе к примеру, почитай про алгоритмы биг о структуры данных, подтяни мат часть и будет тебе счастье

Все норм. Настоящий сыроед

А зачем вы спрашиваете?

Вот еслиб вы писали на Go, то таким вопросом не задавались бы.

Конечно, ведь Го это язык не для программистов

Ну если можешь прогаммировать то да, если можешь только конфиги создать — то нет

Тут ниже напророчили.
Если коротко, как раз «формошлеп» и подойдёт. То есть, вы способны справляться с базовыми бизнес-задачами на требуемом уровне, но одновременно с этим не обладаете достаточно высокой квалификацией.
Если вас беспокоит формальное определение, вы все еще остаетесь программистом, но вероятнее всего — низкоквалифицированным. Если быть более точным, это может соответствовать уровню «кодера».

Подозреваю, что на деле может открыться, что то, с чем вы справляетесь, — тоже лишь на уровне базового АПИ фреймворка/библиотек. На самом деле, вы можете не осознавать в деталях, как работает и расходуются ресурсы сервера (и таким образом создаете боттлнеки). Возможно, вы даже не знакомы с базовыми принципами проектирования БД, нормализациями и прочим подобным (или, еще хуже, не сможете без условной ОРМ написать более-менее сложный селект с джоинами).

Если вам за это платят, — ок, значит это имеет право на жизнь. Но это не оптимально и рискованно — для вас же. Мой личный совет: прокачивайтесь. Я не говорю о задрачивании тонны существующих алгоритмов, но базовые алгоритмические задачки (хотя бы на тех же массивах) стоило бы порешать, просто для прокачки алгоритмического мышления.
Во всем остальном, тоже со временем, после изучения базового АПИ, старайтесь влазить глубже.

Так же можно сказать обо всех, кто свичнулся в разработчики с других специальностей. Люди освоили навыки достаточные для решения задач и работают по шаблону. Времени на освоение фундаментальных вещей информатики у них не было и быстрее всего уже не будет.
Люди просто видят, что больше платят и делают нужную работу. Это больше бизнесовый подход, чем техническое призвание :) но если работает, значит имеет место быть. И конечно будущее развитие, без хорошего фундамента, таким людям предоставляется сложноватым. Все равно придется выучить А, что бы сказать Б. А время то идет, деньги платят и учить столько нового желания все меньше..

я видел на своем пути много code-monkey с образованием программист и что?
Я свичнулся тоже с другой профессии, но я не уверен что знаю намного больше подавляющей части «истинных» программистов

Занятная темка была. Особенно когда набижали фреймворкодрочеры и стали доказывать, что у чувака опыта полгода всего.

Липить цмски это вообшето не опыт программирования

Я все понимаю. Но если наловчится делать таких сайтиков штук 5-10 в месяц по цене 300-500, то уже как-то и не хочется ни опыта труъ программирования, ни на галеру за 500 в месяц с фреймворками. А самое главное доказывать уже больше никому ничего не нужно.

Такие сайтики индусы клепают по 10 баксов за штуку, так что маловероятно что за это столько забашляют

Ок. Пойду найму пару сотен индусов, пусть сидят друпал клепают по десять баксов сайт.

Ох если бы! Они максимум готовую цмс-ку тебе поставят и настроят как им кажется лучше. А если хочешь полноценный шаблон на эту цмс-ку, то плати 200-300 баксов. Хочешь логотипчик рисованный, а не купленный уже тысячным покупателем — еще соточку-две сверху для старта.
Просто если оценивать работу индусов, то они за эти 10-20 баксов обычно предлагают только копипасту из «своей» коллекции копипаст. Дальше уже всё за более серьезное бабло, на которое этот индус будет вас активно разводить.

Так и не получится клепать 5 штук за месяц если кастомно

В этом-то и суть, иначе бы все были фрилансерами :)

Если у вас так получается то конечно не плохо

Получится. У меня минимум 10 либ под себя написанных есть. Практически никогда не начинаю проекты с нуля. То что раньше занимало дней по 14 — сейчас не больше 3-х. Но за друпал ничего не скажу — не пробовал.

Таких как вы единицы :) большинство просто копипастят со стековерфлоу, а потом пытаются понять че не работает

Блииин, администрация не с той плесенью сыр покушала? Как можно на форуме выпиливать жирные темы? Что дальше — про девушек выпилим?

Рискну предположить что он САМ попросил её выпилить, вероятно получив добавки пиз... стимула на текущей галере.

Самое веселое, что программистские темы выпиливают, а вот всякие политически окрашенные с явно антиукраинской риторикой недругов московитов — остаются.

Автор топика зачем-то вот такое сделал с топиком:
s.dou.ua/...​_at_16.38.27-fullpage.png

+1 тем кто знает что это такое :)
+100 тем, кто умеет этим пользоваться :-}>

Ща тебя обосрут и формошлемом назовут.
Программи́ст — специалист, занимающийся непосредственной разработкой программного обеспечения для различного рода вычислительно-операционных систем.

Подписаться на комментарии