• Хватит натягивать сову на глобус
    0
    для бюрократии инцидентов Kanban ну никак не подходит

    Почему?

  • Хватит натягивать сову на глобус
    +1

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


    Единственный профит для бизнеса

    А зачем вообще нужен канбан? С точки зрения его сторонников?

  • Хватит натягивать сову на глобус
    –6

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

  • Что делает Rust универсальным языком программирования
    0

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

  • Microsoft отговаривает пользователей от обновления Windows 10 до версии 2004 — её признали «проблемной»
    +8
    купертиновцы

    Разумеется, к Мак ОС не подходят обновления от винды. Наверное, потому и раньше проблем не было.

  • Что делает Rust универсальным языком программирования
    0

    IDispatch только

  • Что делает Rust универсальным языком программирования
    0
    Обратите внимание, что в исходном примере на Delphi динамика скорее мешает

    По сравнению с гипотетической отсутствующей системой, которая включает генерацию типизированной обертки по TLB, да. Но реально этой системы не существуют, возможно, потому, что ее сложнее делать чем просто вызвать метод IDispatch.Invoke пор строчке. При этом система на основе TLB будет работать только с теми приложениями, которые предоставляют наружу TLB а не всеми для которых работает OLE automation.

  • Что делает Rust универсальным языком программирования
    –3

    Отсутствие проверок типов это и достоинство и недостаток. Как и почти что угодно.


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


    существование генераторов прямо сейчас я не проверял

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


    Например, представьте что вам прямо сейчас надо сделать простой отчет на Excel, сохранить его в PDF и отослать кому-то. Решение будет работать ровно в одной конторе для одного пользователя — бухгалтера Марии Васильевны, что вы выберете?


    Интересно, что в интервью Андрея Бреслава, автора, Котлин "королю программирования" первый сказал, что какие-то возможности динамической типизации есть везде, причем в собственном стартапе они только сейчас доросли до того, чтобы начать применять typescript — cейчас все на JS.

  • Что делает Rust универсальным языком программирования
    0

    А, наоборот — клиента на Раст, который работает с чем-то через COM? Поддержка использования библиотек типов и так далее?

  • Что делает Rust универсальным языком программирования
    –3

    Тем что никак не надо описывать нигде отдельно интерфейс Excel компонентов. И этот код можно скомпилировать на машине без установленного Excel.


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

  • Что делает Rust универсальным языком программирования
    –5

    В примере демонстрируется не какая-то библиотека, а динамические возможности Delphi при интеграции ActiveX компонента. Т.е. там дельфи не знает про excel, а знает только про IDispatch.

  • В Microsoft призвали пользоваться PowerShell. СMD продолжит поддерживаться
    +1

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


    Возможно, для веб разработчика баш удобнее тем, что с ним все равно знаком по серверному линуксу.

  • В Microsoft призвали пользоваться PowerShell. СMD продолжит поддерживаться
    0
    Ну вот вам самому не кажется, что наличие intellisense в PS — это как бы сами разработчики расписались в том, что они сделали настолько плохо, что без подсказок с этим уже как бы и нельзя нормально работать?

    Нет. Просто с подсказками удобнее чем без подсказок.


    Я честно не представляю человека, который в это вот всё полезет добровольно.

    Он удобнее чем CMD только тормознее.

  • В Microsoft призвали пользоваться PowerShell. СMD продолжит поддерживаться
    0

    А как вы без гугла добрались бы до команды dir?
    Можно help Get-* узнать все команды которые что, что получают
    Про параметры есть справка (наберите help dir или dir -?)


    Или intellisence.


    Свойства есть в intellisense или ls | gm


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


    А сейчас есть powershell_ise с intellisense и справка в которой есть поиск и способ изучить структуру выхлопа при помощи gm

  • В Microsoft призвали пользоваться PowerShell. СMD продолжит поддерживаться
    0

    Я не вижу там вообще powershell

  • В Microsoft призвали пользоваться PowerShell. СMD продолжит поддерживаться
    0

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

  • В Microsoft призвали пользоваться PowerShell. СMD продолжит поддерживаться
    0

    Тут имеется ввиду время старта.

  • В Microsoft призвали пользоваться PowerShell. СMD продолжит поддерживаться
    +3
    Они всё так же не интуитивны, догадаться, какой параметр будет, не гугля — почти невозможно

    JFYI


    Имя-Команды -?
    help *ключевое_слово*

    Как-будто в МС засели любители юниксов, но самую важную часть про короткие консольные команды им в детстве никто не рассказал…

    Get-Alias
  • Пять лет Rust
    0
    Nullable не хватит

    Мы говорили про методы try* — они не возвращают ничего о причине, потому, что считают ровно одну причину не исключением, а нормальным ходом выполнения.


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

    Если там было что-то связанное с РСУБД то такой ситуации нет — там и раньше могло упасть.


    "Cannot convert ParseError to io::Error"

    Как в Java checked exceptions, только там, похоже, многие признают это не очень удачной идеей.

  • Пять лет Rust
    –2

    Наличие триллиона TryXXX методов показывают, что всё не так просто. Почему Parse не возвращает Option, а бросает исключение? Почему нет способа получить значение из словаря которого там может не быть (кроме того же неуклюжего TryGetValue)?

    Возможно, потому, что nullable появились не сразу.


    Короче нет, эксепшны это хорошо когда их не надо обрабатывать, но обычно надо обрабатывать или нет знает только код выше.

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


    Это не монотонное засорение. Так, например, если функция раньше всегда возвращала знчение а теперь может упасть, это ломающее изменение.

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


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

    Тут см выше. Транзакции, наверное, бывают разные но в РСУБД, практически все внутри транзакции может упасть.


    В-общем, насколько я понял, из-за упора на системность и быстродействие "исключения везде" для раста не подходят, потму, что это не zero cost abstraction.


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


    Что вы об этом думаете?

  • Пять лет Rust
    0

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


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


    Очень редко нужно делать что-то кроме этих нескольких вариантов (например сгенерировать дамп при oom, retry при разных ситуациях с сетью и блокировках).


    Т.е. умолчания с моей точки зрения позволяют не засорять код монотонным повторением "здесь все как и везде".


    А как у вас? Какую особенную обработку исключений вы делаете?

  • Хватит уже бояться субъективно красивых решений в коде — вы же не роботы
    0

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


    Этот набор компромиссов везде свой, даже у каждого программера свой собственный опыт.


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


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

  • IT — это средний класс с натяжкой. И как НЕ надо проводить собеседование с программистом
    0
    Это не с вашей точки зрения — это ваше предположение о том, что человек который решил опорожнить свой мочевой пузырь на вашей кухне не путылся вас оскорбить. По мне так это предпложение излишне

    Тут наверное зависит от опыта. В моем случае, 100% таких людей были маленькие дети.


    Вот это вам непонятно. Причем временно — все поймете в конечно итоге

    Вы меня переоцениваете.

  • IT — это средний класс с натяжкой. И как НЕ надо проводить собеседование с программистом
    +1
    ну это то понятно — мои интересы вас не волнуют :)

    Это вы про что вообще?


    он просто захотел пописать и реализовал свое желание там, где ему было удобно

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


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

  • IT — это средний класс с натяжкой. И как НЕ надо проводить собеседование с программистом
    +1
    долго объяснять и первое и второе

    Жалко, мне интересен был бы ваш опыт. У меня лично часто оказывается, что разговор про опыт дает более оптимистичное представление о человеке, чем решение задач/вопросы о концепциях.


    расщифровываю — представьте, что вам задают вопросы вроде «а вы моете руки после туалета?»

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


    только мне лень читать чужой код.

    А вы в code review в основной работе участвуете? В чужом коде разбираетесь на основной работе? Просто по моей оценке те примеры, которые можно написать на собеседовании мизер по сравнению с тем что надо читать на работе.

  • Программист не должен решать задачи бизнеса
    +1

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

  • Как делать карьеру программисту, не решая задачи бизнеса
    0

    А гэнти гэмбуцу — японцы!

  • Программист не должен решать задачи бизнеса
    0

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

  • Программист не должен решать задачи бизнеса
    0

    Полезность и уникальность это разные вещи. Уникальность зависит от точности сравнения. Может потребителям нравился другой цвет иконки или другое расположение элементов управления.


    Доширак не хуже обеда в ресторане, он просто для других целей.

  • Программист не должен решать задачи бизнеса
    0
    купить "птичье молоко"

    У кого? Другого бизнеса? Значит есть бизнес который производит птичье молоко?

  • Динамическая типизация — это не инструмент для разработки. Это чепуха (паршивая)
    0
    В моей IDE для хаскеля вообще нет рантайм-меток (да, я за всю практику пользовался Typeable в своём коде ровно один раз). Да и дебаггером я там не пользуюсь.

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


    Кстати, определите до конца термин "рантайм метка" он не отражает метка чего именно.


    В моей IDE для плюсов их тоже не особо много для рантайм-поведения.

    А что у вас за IDE для плюсов? У вас там нет cимволов и RTTI? в окне watch нет колонки type для переменных? Или там написано что-то типа "рантайм метка относящаяся к набору операций которое можно совершать со значением"?


    А зря. На мой взгляд, создаёт неправильные ожидания.

    Какие и у кого?


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

    Я хаскель знаю очень поверхностно. Мне трудно с этим поспорить.


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

  • IT — это средний класс с натяжкой. И как НЕ надо проводить собеседование с программистом
    +1
    1) его опыт как разработчика и/или как интервьюера невелик — что именно мне все равно

    Почему вы так считаете? Как вы сами проводите интервью?


    2) он подозревает, что мои знания и опыт находятся на крайне низком уровне — почему он это подозревает меня не интересует

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


    3) он пытается меня оскорбить — мне безразлично почему именно

    Почему вы воспринимаете это как оскорбление? Можете расшифровать?

  • IT — это средний класс с натяжкой. И как НЕ надо проводить собеседование с программистом
    +1

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


    Мое мнение в целом таково:
    Я не знаю Java в но в случае C# это может до свидетельствовать об опыте кандидата. Например, если он не знает про Equals и GetHashCode, то он не сможет эффективно использовать стандартные коллекции со своими типами.


    Если человек знает про эти методы но не может обобщить разные варианты до ответа на вопрос "зачем нужен метод equals", то, возможно, есть некоторые проблемы с абстрактным мышлением или коммуникацией.


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


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


    Чтобы оценить интервьюера, надо понять, как он использует ответ на вопрос — в какую сторону дальше ведет беседу и так далее.

  • Неудачная статья про ускорение рефлексии
    +1
    Enumerator, который вернет массив, даст прирост или что

    Если вы используете foreach и массив, энумератора вообще не будет. Будет счетчик.


    https://stackoverflow.com/questions/11179156/how-is-foreach-implemented-in-c


    https://sharplab.io/#v2:C4LglgNgNAJiDUAfAAgJgIwFgBQyAMABMugCwDcOyAzEagQMIEDeOBbRNyJBAsgBQBKZq3aiA9GIIA3AIYAnAjIIBeAgDsApgHcCAGTABnYAB5ieAHxMARDKtQCVgEZWAvhWyjRshUtWadANoAuta29k6uZJ7sItGxngBmAPZyGjIAxgAWfN4EYHlqigLxoiwe0Z7EAJx8YALuFQQu8c3YLkA===

  • Динамическая типизация — это не инструмент для разработки. Это чепуха (паршивая)
    +2

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

  • Динамическая типизация — это не инструмент для разработки. Это чепуха (паршивая)
    0
    Ну так и называются, метки.

    А кем они так называются? Есть ли какая-то реализация которая называет их не типом?


    Например, в вашей любимой IDE при отладке тип переменной и тип значения переменной называются по разному? Один тип, другой метка?


    Ээ, не знаю, это какой-то слишком общий термин для меня.

    Ну вы в обычной речи слово тип не употребляете?


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

  • Динамическая типизация — это не инструмент для разработки. Это чепуха (паршивая)
    0

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


    Мне кажется, такой подход к терминологии менее ортогонален.

  • Неудачная статья про ускорение рефлексии
    0
    Тесты не падали. Вы пересмотрели свое отношение к ревью?

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


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


    в реальной жизни заметить разницу между хорошим подходом и плохим достаточно сложно

    У меня такой ход рассуждений:


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


    Почему с этим сложность?
    Потому, что мы сравниваем общую производительность смеси а не по отдельности.


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


    Можно отправить код на ревью вместо использование профайлера, но:


    • это тратит время другого человека, а не инструмента
    • это менее точно (человек может пропустить что-то — инструмент не отвлекается, хотя у него есть свои ограничения)

    зато:


    • человек может что-то подсказать
    • человек, в отличие от профайлера, может проанализировать не только тот сценарий который используется но и другие

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

  • Неудачная статья про ускорение рефлексии
    0
    Код ревью — тоже потеря времени?

    Да, если можно пользоваться инструментом. Например на финальное кодревью надо присылать код в котором не падают тесты и так далее.


    реальной жизни заметить разницу между хорошим подходом и плохим достаточно сложно

    Нет, сложностей нет.

  • Неудачная статья про ускорение рефлексии
    0
    Ошибка была найдена достаточно быстро благодаря комментариям.

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


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

    Не увидели ли бы вы сразу узкое место, если воспользовались профайлером? Может сложность из-за этого?


    А LINQ — это неизбежное зло в бизнес-логике, его просто так не вычистишь.

    Его не нужно вычищать весь. Достаточного только узкие места. Я бы скорее отнес ваш код к инфраструктур не ому уровню чем к бизнес логике.


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

    Не относится ли это рассуждение к любой оптимизации, в том числе и к замене рефлексии тоже?


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

    Тут какая-то описка. Если это то о чем я думаю, то зачем вообще нужна статья, что в ней нового сказано?