Работал с обоими подходами: и когда 2-я линия могла сама фиксить баги, и когда 2-я линия не разработчики, поэтому категоричное утверждение, что "2-я линия состоит из разработчиков" это откуда? Зависит от конкретной организации.
Так вот, в той организации, где 2-я линия состоит из разработчиков от этого в течение времени отказались (жили с этим минимум лет 5, а то и 10), а потом система стало на столько сложной, что сопровождение продукта на 2-й линии просто стало терять контекст и, в итоге, организация перешла к продуктовому подходу. Тут главное не уйти в другую крайность - не свалить задачи сопровождения на команду развития.
Выше про это уже был вопрос. По-моему автор статьи разобрался как работает Hibernate. Вопрос, зачем инвестировать время в его изучение, чтобы, как вы говорите, разобраться? Если есть инструменты, которые решают тот же круг задач проще.
Хотел бы уточнить по поводу зарубежный счетов индивидуального предпринимателя. Что это такое? Разве я могу открыть расчётный счёт за рубежом, будучи ИП в РФ? Или имеется в виду все счета физ. лица, который является ИП в РФ?
Пример, если я получу доход на расчётный счёт в РФ, будучи ИП в РФ, потом выведу средства на свой счёт как физ. лица в банк в РФ, потом переведу эти деньги на иностранный счёт, надо ли мне о таких движениях на иностранном счёте отчитываться ежеквартально или можно ежегодно? Необходимость отчитываться о движениях пропадает у физ. лица в тот момент, когда он перестал быть налоговым резидентом, а для ИП также?
И отдельная нераскрытая тема, как валютное законодательство относится к обмену рублей на криптовалюту и потом продажу криптовалюты за валюту с выводом на иностранный счёт, есть ли здесь ограничения?
Такая строгая типизация работает только для передачи аргументов в функцию.
В коде возможно присвоение любого типа данных.
Например:
function test(integer $i) {
$i = veryStrongCalculation();
return $i; //функция может вернуть любой тип
}
Это пример, написанный сходу.
В реальной программе такая типизация не сможет контролировать ошибочные преобразования.
Т.е. не будет контроля того, для чего строгая типизация вообще придумывалась. Точнее контроль будет очень локальным и частичным, но будет давать опасные предположения о типе переменной. В итоге, вам всё равно надо будет проверять тип, чтобы быть в нём уверенным.
это чудо. Во времена Великих географических открытий люди хоть имели надежду вернуться домой, хотя многие не возвращались. А тут… навесгда. Я бы не согласился. По крайней мере до тех пор, пока не Земле лучше )
Я поздравляю вас, что вы всё точно знаете )
Я занимался электротехникой и эектроникой, знаю как работает компьютер на физическом уровне. Я не про команды на ассемблере, а про физическую реализацию логических элементов на основе транзисторов и т.д., конечно. Вы, надеюсь, тоже знаете? Ведь невозможно без этого точно понимать что скрывается за каждой ассемблерной командой. Да что там ассемблерной, мне посчастливилось увлечься машинным кодом, правда недолго. Интерес интересом, но в работе это не нужно.
Сейчас пишу на языках высокого уровня, а это осталось как хобби. И скажу вам честно, эти знания абсолютно необязательны для программиста на языке высокого уровня.
Если вы представляете как всё реализованно на несокольких уровнях абстракций, то это даёт вам, разумеется, эстетический самолюбовательный бонус, но не более того. Для практики достаточно знать свой уровень и работать с конкретной предоженной моделью без знания внутренних деталей.
А ниже электротехники есть ещё физика.
Вы же не знаете, как взаимодействует материя на уровне квантовой физики? Я вот не знаю, но живу )
Не буду очередной раз повторять всё, что говорят в пользу сторонних и самописных фреймворков. Рассмотрю лишь один аргумент в пользу сторонних фреймворков, который я часто слышу. Он звучит, примерно, так: — Сторонний фреймворк 'X' хорош, потому что если меняется разработчик (или нужен ещё один), то легче найти специалиста, который знает этот фреймворк и время его входа в систему будет минимальным.
Или в другой вариации: — Я разрабатываю сайты под заказ и намного лечге использовать сторнний фреймворк 'X', который реализовал 99% возможных потребностей, чем постоянно дописывать свой велосипед.
Но здесь не учитывается случай, когда программист написал свой фреймворк под конкретный класс задач. И этот фреймворк решает только эту задачу. Например, известный мне реальный случай, когда у программиста свой фреймворк для написания так называемых веб 2.0 приложений, где должен быть профиль, рейтинг, блоги, геотаргетинг и т.д. Такая мини социальная сеть. И ситуация такова, что он работает только с одним заказчиком, у которого все новые проекты именно такие.
А теперь вопрос вхождения новых разработчиков. Да тут всё просто, если даже не учитывать, что отношения заказчика и программиста таковы, что их долгосрочность не вызывает никаких сомнений, то с чего вы взяли, что программисту выгодно использовать сторонний фреймворк? Ведь в таком случае, его будет довольно легко заменить. А если будет фреймворк самописный, то заказчик становится отчасти зависим от программиста. При реальной необходимости, этот программист сможет легко обучить нового программиста фреймворку, который сам же и написал. Для этого, конечно, он должен обладать определённой структурностью. Но мы тут с вами ведь все программисты, что надо? :)
Отсюда вывод, что использование сторонних фреймворков выгодно для заказчика и уменьшает его риски, но не выгодно для разработчика, так как его услуги становятся значительно менее ценными.
А вы тут всё «технологии», «оттестированно», «опробированно», «велосипед». А это всё чисто экономический интерес.
С этой точки зрения, использовать сторонний фреймворк выгодно в собственных проектах, потому что для программиста это легче. Или в случае, если у вас софтверная компания, которая делает сайты под ключ — для скорости выполнения заказов и репутации.
Просто рассазал про случай, когда самописный фреймворк может использоваться. Может уберегу какого-нибудь заказчика от ошибки.
Можно отсортировать список по двумерному параметру. Когда первая часть параметра у обоих объектов равна, то сравнение совершается по второй части.
Из этого следует, что рейтинг можно сделать НЕ линейным, а двумерным. )
Должна, откуда мы пришли, где сейчас и куда идём - вот что такое история.
Работал с обоими подходами: и когда 2-я линия могла сама фиксить баги, и когда 2-я линия не разработчики, поэтому категоричное утверждение, что "2-я линия состоит из разработчиков" это откуда? Зависит от конкретной организации.
Так вот, в той организации, где 2-я линия состоит из разработчиков от этого в течение времени отказались (жили с этим минимум лет 5, а то и 10), а потом система стало на столько сложной, что сопровождение продукта на 2-й линии просто стало терять контекст и, в итоге, организация перешла к продуктовому подходу. Тут главное не уйти в другую крайность - не свалить задачи сопровождения на команду развития.
Выше про это уже был вопрос. По-моему автор статьи разобрался как работает Hibernate. Вопрос, зачем инвестировать время в его изучение, чтобы, как вы говорите, разобраться? Если есть инструменты, которые решают тот же круг задач проще.
Здравствуйте, спасибо за полезную статью.
Хотел бы уточнить по поводу зарубежный счетов индивидуального предпринимателя. Что это такое? Разве я могу открыть расчётный счёт за рубежом, будучи ИП в РФ? Или имеется в виду все счета физ. лица, который является ИП в РФ?
Пример, если я получу доход на расчётный счёт в РФ, будучи ИП в РФ, потом выведу средства на свой счёт как физ. лица в банк в РФ, потом переведу эти деньги на иностранный счёт, надо ли мне о таких движениях на иностранном счёте отчитываться ежеквартально или можно ежегодно? Необходимость отчитываться о движениях пропадает у физ. лица в тот момент, когда он перестал быть налоговым резидентом, а для ИП также?
И отдельная нераскрытая тема, как валютное законодательство относится к обмену рублей на криптовалюту и потом продажу криптовалюты за валюту с выводом на иностранный счёт, есть ли здесь ограничения?
Такая строгая типизация работает только для передачи аргументов в функцию.
В коде возможно присвоение любого типа данных.
Например:
function test(integer $i) {
$i = veryStrongCalculation();
return $i; //функция может вернуть любой тип
}
Это пример, написанный сходу.
В реальной программе такая типизация не сможет контролировать ошибочные преобразования.
Т.е. не будет контроля того, для чего строгая типизация вообще придумывалась. Точнее контроль будет очень локальным и частичным, но будет давать опасные предположения о типе переменной. В итоге, вам всё равно надо будет проверять тип, чтобы быть в нём уверенным.
Лучше вот так
www.php.net/manual/ru/class.splstring.php
викисловарь не согласен.
Не говоря уже о психологическом аспекте.
Воздух — это химическая смесь атмосферы планеты Земля.
Я занимался электротехникой и эектроникой, знаю как работает компьютер на физическом уровне. Я не про команды на ассемблере, а про физическую реализацию логических элементов на основе транзисторов и т.д., конечно. Вы, надеюсь, тоже знаете? Ведь невозможно без этого точно понимать что скрывается за каждой ассемблерной командой. Да что там ассемблерной, мне посчастливилось увлечься машинным кодом, правда недолго. Интерес интересом, но в работе это не нужно.
Сейчас пишу на языках высокого уровня, а это осталось как хобби. И скажу вам честно, эти знания абсолютно необязательны для программиста на языке высокого уровня.
Если вы представляете как всё реализованно на несокольких уровнях абстракций, то это даёт вам, разумеется, эстетический самолюбовательный бонус, но не более того. Для практики достаточно знать свой уровень и работать с конкретной предоженной моделью без знания внутренних деталей.
А ниже электротехники есть ещё физика.
Вы же не знаете, как взаимодействует материя на уровне квантовой физики? Я вот не знаю, но живу )
— Сторонний фреймворк 'X' хорош, потому что если меняется разработчик (или нужен ещё один), то легче найти специалиста, который знает этот фреймворк и время его входа в систему будет минимальным.
Или в другой вариации:
— Я разрабатываю сайты под заказ и намного лечге использовать сторнний фреймворк 'X', который реализовал 99% возможных потребностей, чем постоянно дописывать свой велосипед.
Но здесь не учитывается случай, когда программист написал свой фреймворк под конкретный класс задач. И этот фреймворк решает только эту задачу. Например, известный мне реальный случай, когда у программиста свой фреймворк для написания так называемых веб 2.0 приложений, где должен быть профиль, рейтинг, блоги, геотаргетинг и т.д. Такая мини социальная сеть. И ситуация такова, что он работает только с одним заказчиком, у которого все новые проекты именно такие.
А теперь вопрос вхождения новых разработчиков. Да тут всё просто, если даже не учитывать, что отношения заказчика и программиста таковы, что их долгосрочность не вызывает никаких сомнений, то с чего вы взяли, что программисту выгодно использовать сторонний фреймворк? Ведь в таком случае, его будет довольно легко заменить. А если будет фреймворк самописный, то заказчик становится отчасти зависим от программиста. При реальной необходимости, этот программист сможет легко обучить нового программиста фреймворку, который сам же и написал. Для этого, конечно, он должен обладать определённой структурностью. Но мы тут с вами ведь все программисты, что надо? :)
Отсюда вывод, что использование сторонних фреймворков выгодно для заказчика и уменьшает его риски, но не выгодно для разработчика, так как его услуги становятся значительно менее ценными.
А вы тут всё «технологии», «оттестированно», «опробированно», «велосипед». А это всё чисто экономический интерес.
С этой точки зрения, использовать сторонний фреймворк выгодно в собственных проектах, потому что для программиста это легче. Или в случае, если у вас софтверная компания, которая делает сайты под ключ — для скорости выполнения заказов и репутации.
Просто рассазал про случай, когда самописный фреймворк может использоваться. Может уберегу какого-нибудь заказчика от ошибки.
Из этого следует, что рейтинг можно сделать НЕ линейным, а двумерным. )
А в адресной строке любой современный браузер обрезает параметры.