самое печальное, что в нашей области практически не работает ТК. весь мой опыт - это найм по субподряду. не повторяйте, пожалуйста, этой ошибки, и не вкалывайте как лошади - это чревато проблемами со здоровьем и выгоранием.
дополнения к своему комментарию. я люблю раст и расцениваю его как основной язык разработки. моя имплементация сравнений строк в бд на расте - я собираюсь писать об этом серию статей про сопоставления (collation) в базах данных, сравнениях. в бенчах я превзошел icu4x, и думаю что это интересно для хайлоада, например. работа на низком уровне с памятью - тоже unsafe часть раста, который, с одной стороны, хочет занять нишу высокоуровневого языка с доступом к памяти, с другой стороны - низкоуровневого. тоже момент, который прямо требует статьи
нет. сразу "нет" этой статье. я отвечу с позиции раст-разработчика:
Он быстрый.
да. он быстрый. но в определенных сценариях оптимизация кода совершенно неочевидна.
Он безопасный.
да. если вы пишете обычную либу в обычных условиях. так это и в других языках так. а если вы пишете низкоуровневую библиотеку, где вы можете четко оперировать адресами памяти - вот тут раст может создать препятствия.
Он необычный.
да. когда вы работаете в концепте написания обычного приложения - столкнетесь с отличной штукой - временем жизни переменной.
в остальном - не. я писал на десятках языков, раст - просто изумителен. но - язык.
Он отлично документирован
кстати, поправьте в оригинальной статье "от отлично..". да!!!!!!! офигенная документация. но... тяга к документированию всего вносит свои коррективы. я очень хочу написать статью про вред инлайн-документации для разработки по. может, я и не прав.
все остальное... знаете, раст не решит ваших проблем, если Вы - хреновый программист. не решит проблем когда решите, что O(n) алгоритм на раст быстрее O(log n) алгоритма на javascript в случае веба. раст - хороший язык, когда вы знаете, что хотите. как в си, например. но - раст. и я очень люблю этот язык.
спасибо, схоронил ) немного оффтопик, но - по опыту, раст прямо-таки создан для различного рода оптимизаций. сейчас пишу имплементацию сопоставлений unicode для своей бд, так на нормализации добился до 40% прироста по сравнению с ICU4X.
приятно увидеть людей со схожими взглядами на код )
+1, но немного дополню. можно сделать такое решение - буфер, сочетающий в себе данные на стеке и аллокацию из кучи -
pub struct TinyBuffer<T: Copy, const S: usize> {
/// небольшой буфер, используемый по умолчанию, чтобы избежать лишнего обращения к аллокатору
tiny: [MaybeUninit<T>; S],
/// количество элементов буфера
length: usize,
/// вместимость текущей ячейки
capacity: usize,
/// указатель на первый элемент буфера
pointer: *mut T,
}
бывает так - есть выбранное решение, и оно устраивает на момент покупки. бизнес-процессы выстроены, всё для всех удобно. далее идет развитие системы, она предлагает новые опции, новые фишки, которые зачастую не согласуются с принятыми в компании процессами - и новые сотрудники, например, начинают их использование. я сейчас описываю несовершенный мир, в котором мы живем, а не тот, где прям - обновление прилетело и бабочки запорхали. что мы можем получить? бардак, несогласованность метрик (их ведь тоже кто-то писал, полагаясь на старые подходы?), да черте-что ещё. упрощение пользовательского опыта ведет к усложнению общей схемы при обновлениях общей системы. тоже проблема, вобщем-то.
"Если базовая ячейка равна 5, то 25x25" - старайтесь не использовать размеры, не кратные двум. рискуете получить размытые линии при скейле (что логично)
проверяйте элементы иконки на привязку к сетке / целочисленным значениям. дробные значения координат - путь к нечетким линиям. казалось-бы - элементарщина, но при спешке и использовании каких-то сторонних ассетов может всплыть
немного бы поспорил / расширил 3й пункт. придерживаться стоит не только одинаковой толщины линий, но и одинакового (или кратного толщине линий) расстояния между линиями. опять же - в зависимости от выбранной стилистики, допустимо использовать линии с толщиной, кратной основной на иконках с размером больше, например, 16x16. но количество вариантов должно быть строго ограничено. на "неверном" примере в 3м пункте - есть основная толщина (x), и толщина менее значимых элементов (0.5x). как по мне - это вполне допустимо (но, повторюсь, не на маленьких размерах иконок). вкусовщина, конечно.
статья довольно невнятная, если не вредная. какое предназначение у этого синтаксического сахара? удобство/читаемость? тогда почему в этом контексте упомянут обмен данными между серверами, где это вредно (вот тут можно рассказать про msgpack).
простите, побуду занудой - но после прочтения заголовка, у меня возник вопрос - всё-таки, почему-же вот именно я, почти что 40-летний разработчик, должен получить статус студента на гитхабе вот прямо сейчас?
есть такое мнение, что кликбейтные заголовки - не очень хорошая штука.
здравствуйте, а можно немного деталей? ну, поддержка форматов в целом, вообще цель софта - редактор миди или нотный, поддерживает-ли по-человечески многоголосье, совместимость, например, с сибелиусом
блин. вот мы говорим - как слепой с глухим, простите еще раз.
наверное, чуть позже смогу более адекватно формулировать свои мысли и попробую сделать наброски статьи на тему. надеюсь, не скачусь в этом в тематику "как все плохо". обещаю - постараюсь! )
извините, но это все очень спорно на больших проектах.
ни один инструмент не ультимативен.
хочу сказать еще, что так называемые "преимущества", использование bem как единственной альтернативы.. знаете, пока Вы не умеете это всё готовить. верстка, стилизация - это на самом деле не так сложно, если отойти от кучи вспомогательных инструментов и взглянуть на задачу, и тем более стилизованные компоненты не решают задачу сложности css - значит, у Вас просто что-то не так.
верстаю больше 20 лет, я понимаю, что это не аргументный аргумент. тем не менее - этот подход, как любой другой - красив и удобен в своем случае.
с наступившим новым годом, такой боевой настрой насчет фронта - вера в то, что есть энтузиасты) добра!
мы говорим на разных языках. настройки - я имею ввиду ux группировка настроек. ui - исправляются одной темой - так, блин, дайте по дефолту то, что не надо исправлять.
вот такие вот хотелки. простите, возможно мне не так удается формулировать свои мысли - я с людьми не так часто общаюсь, простите
ну да, в данном конкретном случае я имею ввиду гном. вопрос в какую сторону - почему эти все дистры из коробки ui-убогие? вот именно в этом и состоит мой вопрос.
"начало пути" != отсутствие специалиста по ui/ux. очень большая проблема, на мой взгляд - "а давайте как тогда, как нам нравилось". вот и проблемы - интерфейс - как кажется разработчикам - технически нормальный, но по факту - ужас для пользователя. дурные рамочки, отсутствие общей цветовой схемы, отступов, вообще концепции. не начало, а отсутствие. ux - ну, например, настройки. давайте не будем заморачиваться, все раскидаем по 100500 разным разделам, элементы управления будут зависеть от кодера а не от удобства.
хм. писать в чат, когда буянит пассажир? или прикрутили распознавание речи?
Наш системный и бизнес аналитик полгода находились в офисе S7 Airlines в Домодедово для изучения более 23 малоописанных систем интеграции с бесконечным разнообразием данных. Около года понадобилось, чтобы все данные приходили корректно и были корректно связаны друг с другом.
звучит как какой-то нереальный героизм. вот очень бы хотелось про внутренние процессы почитать - как был организован процесс, как проходили согласования, проектирование, у кого из аналитиков первым начал дергаться глаз, появился нервный тик.. ))
Тильда — побитовое отрицание, одно неловкое движение — — и мы получаем не то, что хотим.
По самому же вопросу — да, с одной стороны это удобно. Но, на мой взгляд, введение оператора прозвучит как призыв опять размыть границы между логикой и шаблоном, яркий пример чего — печально известный код CMS-Которую-Нельзя-Называть.
самое печальное, что в нашей области практически не работает ТК. весь мой опыт - это найм по субподряду. не повторяйте, пожалуйста, этой ошибки, и не вкалывайте как лошади - это чревато проблемами со здоровьем и выгоранием.
дополнения к своему комментарию. я люблю раст и расцениваю его как основной язык разработки. моя имплементация сравнений строк в бд на расте - я собираюсь писать об этом серию статей про сопоставления (collation) в базах данных, сравнениях. в бенчах я превзошел icu4x, и думаю что это интересно для хайлоада, например.
работа на низком уровне с памятью - тоже unsafe часть раста, который, с одной стороны, хочет занять нишу высокоуровневого языка с доступом к памяти, с другой стороны - низкоуровневого. тоже момент, который прямо требует статьи
нет. сразу "нет" этой статье. я отвечу с позиции раст-разработчика:
Он быстрый.
да. он быстрый. но в определенных сценариях оптимизация кода совершенно неочевидна.
Он безопасный.
да. если вы пишете обычную либу в обычных условиях. так это и в других языках так.
а если вы пишете низкоуровневую библиотеку, где вы можете четко оперировать адресами памяти - вот тут раст может создать препятствия.
Он необычный.
да. когда вы работаете в концепте написания обычного приложения - столкнетесь с отличной штукой - временем жизни переменной.
в остальном - не. я писал на десятках языков, раст - просто изумителен. но - язык.
Он отлично документирован
кстати, поправьте в оригинальной статье "от отлично..".
да!!!!!!! офигенная документация. но... тяга к документированию всего вносит свои коррективы. я очень хочу написать статью про вред инлайн-документации для разработки по. может, я и не прав.
все остальное... знаете, раст не решит ваших проблем, если Вы - хреновый программист. не решит проблем когда решите, что O(n) алгоритм на раст быстрее O(log n) алгоритма на javascript в случае веба. раст - хороший язык, когда вы знаете, что хотите. как в си, например. но - раст. и я очень люблю этот язык.
спасибо, схоронил ) немного оффтопик, но - по опыту, раст прямо-таки создан для различного рода оптимизаций. сейчас пишу имплементацию сопоставлений unicode для своей бд, так на нормализации добился до 40% прироста по сравнению с ICU4X.
приятно увидеть людей со схожими взглядами на код )
+1, но немного дополню. можно сделать такое решение - буфер, сочетающий в себе данные на стеке и аллокацию из кучи -
бывает так - есть выбранное решение, и оно устраивает на момент покупки. бизнес-процессы выстроены, всё для всех удобно. далее идет развитие системы, она предлагает новые опции, новые фишки, которые зачастую не согласуются с принятыми в компании процессами - и новые сотрудники, например, начинают их использование.
я сейчас описываю несовершенный мир, в котором мы живем, а не тот, где прям - обновление прилетело и бабочки запорхали.
что мы можем получить? бардак, несогласованность метрик (их ведь тоже кто-то писал, полагаясь на старые подходы?), да черте-что ещё.
упрощение пользовательского опыта ведет к усложнению общей схемы при обновлениях общей системы. тоже проблема, вобщем-то.
маленькое дополнение:
"Если базовая ячейка равна 5, то 25x25" - старайтесь не использовать размеры, не кратные двум. рискуете получить размытые линии при скейле (что логично)
проверяйте элементы иконки на привязку к сетке / целочисленным значениям. дробные значения координат - путь к нечетким линиям. казалось-бы - элементарщина, но при спешке и использовании каких-то сторонних ассетов может всплыть
немного бы поспорил / расширил 3й пункт.
придерживаться стоит не только одинаковой толщины линий, но и одинакового (или кратного толщине линий) расстояния между линиями.
опять же - в зависимости от выбранной стилистики, допустимо использовать линии с толщиной, кратной основной на иконках с размером больше, например, 16x16. но количество вариантов должно быть строго ограничено. на "неверном" примере в 3м пункте - есть основная толщина (x), и толщина менее значимых элементов (0.5x). как по мне - это вполне допустимо (но, повторюсь, не на маленьких размерах иконок). вкусовщина, конечно.
статья довольно невнятная, если не вредная. какое предназначение у этого синтаксического сахара? удобство/читаемость? тогда почему в этом контексте упомянут обмен данными между серверами, где это вредно (вот тут можно рассказать про msgpack).
простите, побуду занудой - но после прочтения заголовка, у меня возник вопрос - всё-таки, почему-же вот именно я, почти что 40-летний разработчик, должен получить статус студента на гитхабе вот прямо сейчас?
есть такое мнение, что кликбейтные заголовки - не очень хорошая штука.
здравствуйте, а можно немного деталей? ну, поддержка форматов в целом, вообще цель софта - редактор миди или нотный, поддерживает-ли по-человечески многоголосье, совместимость, например, с сибелиусом
блин. вот мы говорим - как слепой с глухим, простите еще раз.
наверное, чуть позже смогу более адекватно формулировать свои мысли и попробую сделать наброски статьи на тему. надеюсь, не скачусь в этом в тематику "как все плохо". обещаю - постараюсь! )
извините, но это все очень спорно на больших проектах.
ни один инструмент не ультимативен.
хочу сказать еще, что так называемые "преимущества", использование bem как единственной альтернативы.. знаете, пока Вы не умеете это всё готовить. верстка, стилизация - это на самом деле не так сложно, если отойти от кучи вспомогательных инструментов и взглянуть на задачу, и тем более стилизованные компоненты не решают задачу сложности css - значит, у Вас просто что-то не так.
верстаю больше 20 лет, я понимаю, что это не аргументный аргумент. тем не менее - этот подход, как любой другой - красив и удобен в своем случае.
с наступившим новым годом, такой боевой настрой насчет фронта - вера в то, что есть энтузиасты) добра!
мы говорим на разных языках. настройки - я имею ввиду ux группировка настроек. ui - исправляются одной темой - так, блин, дайте по дефолту то, что не надо исправлять.
вот такие вот хотелки. простите, возможно мне не так удается формулировать свои мысли - я с людьми не так часто общаюсь, простите
ну да, в данном конкретном случае я имею ввиду гном. вопрос в какую сторону - почему эти все дистры из коробки ui-убогие? вот именно в этом и состоит мой вопрос.
"начало пути" != отсутствие специалиста по ui/ux. очень большая проблема, на мой взгляд - "а давайте как тогда, как нам нравилось". вот и проблемы - интерфейс - как кажется разработчикам - технически нормальный, но по факту - ужас для пользователя. дурные рамочки, отсутствие общей цветовой схемы, отступов, вообще концепции. не начало, а отсутствие. ux - ну, например, настройки. давайте не будем заморачиваться, все раскидаем по 100500 разным разделам, элементы управления будут зависеть от кодера а не от удобства.
печально все это, знаете..
да даже в убунте?
вот с чем, а с UI/UX у них всех какая-то беда.
хм. писать в чат, когда буянит пассажир? или прикрутили распознавание речи?
звучит как какой-то нереальный героизм. вот очень бы хотелось про внутренние процессы почитать - как был организован процесс, как проходили согласования, проектирование, у кого из аналитиков первым начал дергаться глаз, появился нервный тик.. ))
<?=~$foo;?>— прошу прощения, не разобрался с допустимыми тегами.По самому же вопросу — да, с одной стороны это удобно. Но, на мой взгляд, введение оператора прозвучит как призыв опять размыть границы между логикой и шаблоном, яркий пример чего — печально известный код CMS-Которую-Нельзя-Называть.