Join Yalantis and get a $1000 sign-in bonus! React.js, React Native, Python, Java, DevOps, BА. Apply now!
×Закрыть
Oracle PL/SQL TechLead в Dukascopy Bank
  • Про инженеров и программистов

    Что касается его книги — там чисто философские рассуждения на околонаучные темы.
    Давайте спорить о вкусе устриц с теми, кто их ел :-)
    Поддержал: Anton Khristiansen
  • С Пасхой!

    Введение Бога ограничивает нас в познании.
    Так а мы по-любому ограничены в познании. Наш мир 3-мерный + с натяжкой можно взять 4 измерение — время, но движемся мы по нему строго вперед. Вот теперь скажите, как мы можем познавать 4-5-n мерные миры нашими 3-мерными научными методами? А никак. Более того, какие-нибудь 4-мерные существа, которые свободно перемещаются в любую точку времени как мы в любую точку в пространстве, так же не смогут познать нас. У них в принципе будет отсутствовать понимание специфики нашего бытия. Да они даже на контакт с нами выйти, скорее всего, не смогут, т.к. для этого нужно четко зафиксировать себя в некой временной точке... А Вы говорите — Бог...
  • С Пасхой!

    Запросто. Давайте поиграем в игру «Что это». Предмет можете выбрать сами, любой. И задавайте один единственный вопрос: «Что это»? К ответу снова задавайте вопрос: «Что это»? Рано или поздно Вы обязательно окажетесь в затруднении очередного ответа. И не только Вы, любой человек. Более того, согласитесь, что не может быть в нашей реальности «последнего» вопроса «Что это»? Т.к. за вопросом обязательно будет следовать предположение наличия ответа, этого «нечто», к которому опять можно будет поставить вопрос «Что это»...

    Так вот, в таких случаях мы просто вынуждены ввести некое понятие, которое является отправной точкой всех остальных рассуждений. Называйте его как хотите: Бог, Вселенная, Природа, Мироздание и т.д. Я называю его Богом, для удобства. И этим понятием мы затыкаем дыру вечного вопроса, чтобы как-то выйти из этого бесконечного цикла...

  • С Пасхой!

    Так не получается не домешивать... Как только мы начинаем углубляться в рассмотрение какой-либо тематики научного толка, так в скором времени упираемся в некий барьер, который мы объяснить с научной точки зрения ну никак не можем. Приходится вводить Бога в нашу модель, иначе все рушится.

    Не может Замкнутая Система (коей является наша Вселенная) целиком и полностью объяснить сама себя изнутри. Поэтому (ИМХО) и необходимо вводить понятие Бога — некой сущности, не принадлежащей нашей Системе. И затыкать «этой сущностью» все возникающие дыры и парадоксы. Иначе никак...

  • Про инженеров и программистов

    эту «библию» написал какой-нибудь бывший сантехник
    Эх, поизмельчал нынче наш брат-программист. Если для Вас Стив МакКоннелл является «бывшим сантехником», то спорить не буду. Даже не удивлюсь, если Вы не знаете, кто это...
  • Про инженеров и программистов

    И вот тут начинаются критические проблемы.
    Хорошо, давайте рассмотрим критичность этих проблем детальнее...
    что автотесты ничего не решают
    Хорошо, допустим, что автотесты ничего не решают. Исключаем их из рабочего процесса, нечего заморачиваться и тратить x2 времени на эту бесполезную ничего не решающую затею.
    модель ей соответствует только в определенный пределах ис определенной точностью.
    Так а кто же спорит? Совершенно верно. И чем конкретнее, понятнее будут описаны эти пределы и допустимая точность, тем точнее будет реализация ПО для обеспечения функционирования этой модели.
    Выйдет ли эта модель за пределы истинности зависит от понимания
    Так я с этим и не спорю. Шерлоку тоже необходимо было глубинное понимание сыскной деятельности и смежных с этим сфер. Но совсем бесполезным и даже вредным (с его точки зрения) было понимание принципов существования Солнечной Системы. Они им ни в каком виде не применялись...
    Если бы вы были программистом
    Не обижайтесь, но сразу видно «инженера-теоретика». И снова отвечу Вам цитатой, но уже ближе к нашей, программистской теме. Автора и название книги давать не буду, это Библия программиста-практика:

    Интеллект не кажется чертой характера и на самом деле не является им. Высочайший уровень интеллекта — далеко не главное условие для человека, желающего стать хорошим программистом, Что? Для этого не НУЖНО быть суперинтеллектуальным?
    Нет, не нужно. Никто не обладает достаточным для программирования уровнем интеллекта. Чтобы полностью охватить и понять сразу все детали даже средней программы, человек должен был бы обладать почти неограниченными возможностями. Способ использования интеллекта важнее, чем его уровень...

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

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

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

    Поддержали: Valentin Nechayev, Olexandr Vovchok
  • Бази даних — декілька запитань

    К сожалению, тут не подскажу. Я специализируюсь на Базах Данных, а в ПХП разбираюсь чуть лучше, чем свинья в апельсинах :-)

  • Про инженеров и программистов

    Смешались в кучу кони, люди... Инженеры, архитекторы, программисты...
    У меня такое ощущение, что уважаемые форумчане ведут обсуждение не в определении этих категорий с точки зрения топикстартера, а в определении в соответствии со своим ИМХО. Из-за этого общий язык и не найдем, т.к. отсутствует соглашение в определении темы спора :-)

    типичный программист понятия не имеет о том, как функционирует не то что двигатель его автомобиля, но даже компьютер, за которым он работает.
    Типичному программисту (не кодеру!) главное понимать окружение и термины той задачи, для которой он пишет ПО. А окружение это может быть очень разным: банковская сфера, медицина, спутники и т.д. И для каждой из этих сфер программист должен иметь весьма и весьма специфические знания. Согласитесь, программисту банковской сферы совсем необязательно знать скорость света в вакууме, хотя программисту спутника такое знание в подсознании уже зашито...
    Да, существует масса инженеров и программистов в одном флаконе, но таких с годами почему-то все меньше и меньше.
    А почему так? Ответ ведь на поверхности: не нужен такой специалист Заказчику. Узкоспециализированного им подавай...
    И результат этого мы постоянно наблюдаем в виде производственных фейлов
    Знаете, мне смешно, когда результат подобных фэйлов списывают на «ошибку программиста». Извините, если при запуске космического аппарата ПО не прогнали «в хвост и в гриву» через автотесты и разного рода симуляторы, а запустили как есть, в надежде на то, что «программист не ошибается» — то и видим падающие ракеты, сходящие с орбиты спутники и т.д. Производственный косяк — это косяк всего ПРОЦЕССА, а не только программиста...
    А к тому, что нужно развиваться не только в сторону знания различий ES5 и ES6.
    Согласен. Но более разумно развиваться в своей области + смежных областях, а не вообще. Если ты не занимаешься разработкой ПО в сфере авиации , то тебе совсем необязательно знать принцип работы турбореактивного двигателя. Почему так? Отвечу цитатой известного литературного персонажа, который был одним из лучших специалистов В СВОЕМ деле:

    Шерлок Холмс: Коперник? Знакомая фамилия. Что он сделал?
    Доктор Ватсон: Боже мой, так ведь это же он открыл, что Земля вращается вокруг Солнца! Или этот факт вам тоже неизвестен?
    Шерлок Холмс: Но мои глаза говорят мне, что, скорее, Солнце вращается вокруг Земли. Впрочем, может быть, он и прав, ваш... как его — Коперник.
    Доктор Ватсон: Простите меня, Холмс... Вы человек острого ума, это сразу видно! Вы превосходно знаете химию... Как же Вы не знаете... вещей, которые известны каждому школьнику?!
    Шерлок Холмс: Ну, когда я был школьником, я это знал, а потом основательно забыл.
    Доктор Ватсон: Вы что, хвастаетесь своим невежеством?!
    Шерлок Холмс: А Вы, Ватсон, можете отличить грязь на Ридженс-стрит от грязи на Пиккадилли? Или пепел гаванской сигары от пепла манильской? Или можете мне сказать, что написано в третьем параграфе «Уложения о наказаниях Британской империи»? Можете?
    Доктор Ватсон: Но ведь я говорю об элементарных вещах, которые знает каждый!
    Шерлок Холмс: Но я-то не каждый, Ватсон, поймите: человеческий мозг — это пустой чердак, куда можно набить всё, что угодно. Дурак так и делает: тащит туда нужное и ненужное. И наконец наступает момент, когда самую необходимую вещь туда уже не запихнёшь. Или она запрятана так далеко, что её не достанешь. Я делаю по-другому. В моём чердаке только необходимые мне инструменты. Их много, но они в идеальном порядке и всегда под рукой. А лишнего хлама мне не нужно.
    Доктор Ватсон: Учение... Коперника... по-Вашему, хлам?!
    Шерлок Холмс: Хорошо. Допустим, Земля вращается вокруг Солнца.
    Доктор Ватсон: То есть... то есть... ка́к — допустим?!
    Шерлок Холмс: Земля вращается вокруг Солнца. Но мне в моём деле это не пригодится!
  • Бази даних — декілька запитань

    Здравствуйте!

    Як зберегти файл у базу даних ? Чи можна його взагалі зберігати ?
    В зависимости от БД, применяются разные подходы. В одних СУБД сохранение такого типа информации ОБЯЗАТЕЛЬНО должно идти отдельной инструкцией, в других — нет. Подозреваю, есть СУБД, которые не позволяют хранить такой тип данных. Без детализации используемой СУБД ответить точно и правильно невозможно...
    Який тип таблиць потрібний ?
    В большинстве случаев, необходимо определить тип КОЛОНКИ таблицы как BLOB. Если храните картинки на сервере СУБД — то возможно применение типов а-ля FILE и им подобных...

    Но мое ИМХО: хранить информацию подобного рода на сервере БД \ в таблицах БД не то что запрещено, но неверно с архитектурной точки зрения. Почему? Спросите у администраторов БД, они доходчиво, понятливо и в красках расскажут детали... :-)

    Поддержал: Нестор Иванович
  • Как вы относитесь к Technical writing/Business Analysis задачам для программистов?

    Мой вопрос нормально ли это?
    Если Вы кодер либо джун — ненормально.
    Если мидл+ - «тыжпрограммист»
    ИМХО
  • Где и как найти тех. ментора?

    Давайте рассуждать логически.
    1. Вы имеете несколько узких мест, которые мешают эффективно развивать ПО для удовлетворения потребностей бизнеса.
    2. Детальное осознание этого факта — есть.
    3. Вы считаете, что поиск решения командой разработчиков в текущем составе — не самое оптимальное решение.

    Ок, допустим, Вам подскажут конкретного Консультанта. Как Вы будете оценивать его профессионализм в данном вопросе (это нужно сделать еще до начала сотрудничества) и результаты его анализа (и если я правильно понял, внедрять эти результаты будет Ваша команда)?

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

    Мое видение такое: делайте ставку на Команду. Если Команда в жутком цейтноте — то это другой вопрос. Значит, необходимо расширение. Или выделение времени на решение технических проблем в ущерб бизнес-функционалу. И четкое обоснование это для Бизнеса на языке, понятному ему: в терминах возможных расходов, убытков, репутационных потерь и т.д.

  • Развитие от Junior до Middle (Android dev.)

    Кодить это никак не стыдно и не низко.
    Именно. В принципе, все с этого начинают. И это не стыдно, это факт. И на кодинге можно остановиться в своем профессиональном развитии. Если перефразировать классика: «Стране всегда нужны хорошие счетоводы кодеры».

    Но чтобы достичь бОльшего, нужно уже мыслить категориями Продукта. И как по мне, именно это отличает хорошего Синьора от хорошего Миддла. Эдакий Рубикон...

  • Развитие от Junior до Middle (Android dev.)

    поэтому скорее можно сформулировать цель не «Как дойти до Middle», а «как развиваться в целом»
    Если попытаться выразить путь развития одной фразой, то она бы выглядела как-то так: «Кодеры — пишут код. Разработчики — создают продукт.»
    Поддержал: Volodymyr Spodaryk
  • [Київ] Що робити з орендодавцем квартири який зненацька привязався до курсу валют?

  • Оракл уволил Джава евангелистов

    Похоже, намечается альтернативная ветвь развития:
    www.oracle.com/.../last-asktom-2650480.html

  • Выбор стороны Силы

    быстрого выгорания из-за того, что язык тебе не по душе.
    Великие классики глаголят: «Программируйте с использованием языка, а не на языке». Тогда и выгорания не будет...
    Поддержал: Sergey Sheshenya
  • Выбор стороны Силы

    время реализации бизнес-логики на pl/sql, да и на бэке вообще, потихоньку проходит
    Best-practices процессов разработки ПО имеют тенденцию к приверженности моде. Появилось ООП — начали использовать где нужно, и где не нужно (СУБД Oracle в этом отношении очень хороший пример). Пришла мода на Application-сервера — начали где нужно, и где не нужно использовать. И так далее.

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

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

    Конечно, если смотреть по вакансиям, то предпочтение отдается специалистам со знаниями СУБД + ЯП. Но думаю, на наш век работы для «узкозаточенных» специалистов по СУБД (независимо от ее названия) точно хватит...

  • Выбор стороны Силы

    Вопрос: какой выбрать ЯП для дальнейшего изучения, чтобы в связке с СУБД Оракл
    Если постараться, то связка не обязательна. ЯП приходящее, СУБД — вечное...
  • Валютні кредити V2

  • Обсуждение ограничений на наличные

    Только одним: драконовскими комиссиями украинских банков.
    На зарплатные карты физлиц? Назовите мне хотя бы один банк из топ-10, кот. на данный момент имеет такую комиссию. В будущем, конечно, ничто не помешает такую комиссию ввести, но ничто не помешает также найти кучу способов такую комиссию не платить.
    Ну и государство в стороне не останется, изыскав способы прямого изъятия денег на свои нужды.
    Вот с этим я полностью согласен. Но тогда что помешает населению хранить на банковских картах суммы, необходимые для текущего месячного потребления, а остальное — «под матрасом»?
    Как мне кажется, как раз здесь Банковский Сектор должен быть заинтересован в как можно мЕньшем волнении населения по поводу сохранности средств. Иначе «не понесут», или «очень быстро вынесут».
    Но не в этом государстве!
    Так а другого нет.
← Сtrl 1... 222324252627 Ctrl →