Манкипатчингом можно и в JS заниматься, но я не считаю это поводом для гордости.
Я не monkey patching имел в виду, а читабельность кода. Когда что-то не получается или не знаешь, как сделать, весьма ценно бывает залезть в исходники фреймворка и посмотреть, как сделано то или это. Частенько и находишь, какую настройку подвинтить.
Ext JS далеко не идеален, но даже в 2011 читался существенно лучше, чем многие конкуренты по цеху. А с тех пор чуть-чуть улучшился. :)
В современных UI-либах (в крайнем проекте использовал react-toolbox) просто нет необходимости где-то там патчить.
Багов в них тоже нет, чтобы не было необходимости патчить?
Я слежу периодически за обновлениями компании Sencha. Вот у них и React-компоненты появились, тренд понятно куда ведет.
Это как раз попытка выехать на тренде и заработать денег.
Это Sencha CMD хороший инструмент? Вы серьезно?
Я Ext JS имел в виду. Сам не большой фанат Cmd, но этот инструмент тоже легко недооценить. С первого взгляда это кривая и архаичная поделка для склеивания JavaScript файлов, но на самом деле Cmd умеет очень много разных интересных штук. Например, запускать тестовые сессии через WebDriver, с параллелизацией, очерёдностью, сбором статистики, свистелкам и перделками. ~500,000 юнит-тестов за полчаса, и так на каждый pull request. Просто для справки. :)
Вообще ни при чём, кроме того, что многие организации до сих пор Windows 7 используют и IE11. И модернизироваться не собираются. А некоторые даже за поддержку Windows XP и IE8 платят, дураки несолидные.
Ну, вам-то там в воображаемом мире конечно недосуг во все такие мелочи вникать. У вас там бабочки порхают, единороги прыгают, и все юзеры только пальчиками в айфоны последней модели тыкают.
Миксины много кто не умеет. Да и можно достичь подобия через анонимные классы и HOF
Мне всё равно, кто что не умеет. Я отвечал на вопрос: а чем таким плохая, негодная, архаичная классовая система Ext JS может быть лучше модной, годной, молодёжной ES6. Спрашивали? Отвечаем.
Подобия достигайте, ваше дело. Тестами закрыть не забудьте только, а то открытий чудных много предстоит вам. Опять же из опыта говорю.
Все умеют
Условные тоже, и декларативно? Приведите примеры, если не сложно.
Какие еще хуки?
Да простые, типа таких: onBeforeClassCreated, onClassExtended, etc. Чем они могут оказаться полезны, объяснить или сами догадаетесь?
Какой еще resolution в динамическом языке?
Да вот такой, простой. Класс Foo зависит от класса Bar, и использует Qux. При загрузке класс Foo не создаётся, пока не загрузятся Bar и Qux, со всеми своими зависимостями.
И в динамическом языке, ага. Работает уже лет 8 как. И инструментарием поддерживается для сборки. А вы дальше там простыни import-ов ручками пишите, удачи.
Все умеют
Статические свойства классов. Вы давайте, приводите примеры в ES6, не стесняйтесь. Я-то свои слова подкрепить могу в любой момент, зря что ли этот кусок перелопачивал и тестами закрывал. :P
Если хочется какого-то нестандартного поведения, для которого у разработчиков не предусмотрен готовый флаг, то придется перелопатить очень много кода, чтобы найти что где переопределяется.
Но ведь, что интересно, удавалось же? Я помню, как примерно в те же года пытался разобраться в Dojo. Вот уж где спагетти было жестокое. После него Ext JS 4 при всей своей лютой, бешеной глючности казался всё же глотком свежего воздуха.
Об этом я даже в 2011 году написал статью.
С тех пор чуток воды утекло. Вы считаете нормальным сравнивать фреймворк 6-летней давности с современными решениями?
После того, как я познакомился с Grunt, Webpack и современным фронтенд-стеком в целом, обратно меня уже никакими рассказами про "на порядок более богатые" классы не заманить.
А у меня вот наоборот: сколько ни смотрю на этот "современный фронтент-стек", столько и плакать хочется. Избалован доступом к хорошим инструментам, чего уж там. :(
Сейчас как раз пытаюсь потихоньку выбрать, на чём делать новый личный проект. Ext JS использовать очень не хочется по личным причинам, но всё остальное даже рядом не валялось. Хоть всё бросай и начинай свой фреймворк, с блекджеком и прочими штуками...
Кое-как работают, там, где они есть. В IE11 есть? Ой, нет. А что умеют? Ой, почти ничего не умеют. Mixins умеют? Нет. Overrides умеют? Нет. Hooks умеют? Нет. Dependency resolution умеют? Нет. Господи, ну хоть статические свойства классов-то умеют? Неа, всё ручками. Пилите, Шура, пилите...
Вообще очень печально, если вы не можете понять чем хороши все эти новые недо-фичи в сравнении с весьма спорными и давно устаревшими подходами в Ext.
Вообще очень печально, если вы не можете понять разницу между решениями хайпо-модно-молодёжными и реально полезными. Впрочем, это не только ваша проблема, это общая головная боль по больной на голову индустрии.
но это не делает webpack менее крутым.
Чем конкретно крут webpack? По пунктам, если не трудно; бонусные баллы за объективное сравнение с другими решениями. Подозреваю, что дальше "webpack крут, потому что его Angular же использует!" вы не уйдёте.
Ну хотите верьте, хотите нет — работал с Ext не один год. Безусловно такой библиотеки контролов нет и не будет ни для одной из описанных библиотек/фреймворков.
Да чего ж не верить? Верю. Печально, что кроме библиотеки виджетов вы ничего не заметили или не оценили.
Ну так зато они не стоят тысяч долларов, а бесплатны и опенсорсны.
Вы мне сейчас напоминаете этот бородатый анекдот про солидную компанию с богатой историей, которая наймёт на пол-ставки студентов на подработку. Обещаем доширак сильно не задерживать!
А полноценные гриды в серьезных компаниях чаще пишутся либо самостоятельно. Нам в нашем проект Clarity хватило.
У нас с вами очень разные понятия о полноценности таких интересных компонентов, как grids. И об уровне допустимого качества, очевидно, тоже. И даже, рискну предположить, "сёрьезность" компаний мы воспринимаем весьма по-разному; хотя, на мой взгляд, тут дело скорее в задачах, нежели в компаниях.
Я бы мог много разных примеров из опыта привести, скажем про одного несолидного немецкого производителя люксовых авто, которому приспичило запихнуть навигацию/просмотр/редактирование базы из ~9 млрд парт-номеров запчастей в один TreeGrid. С "бесконечной" прокруткой, страничной подкачкой по запросу и прочими весёлыми штуками. Ну, вот дураки там сидят, не осилили сами-то запилить.
Или про один забавный и крайне несолидный НИИ в Швейцарии, который там коллайдеры всякие гоняет туда-сюда, а данных-то с них 100500 терабайт или что-то такое. Визуализировать надо, для обработки и анализа. Тоже идиоты, ха-ха, да плёвое ж дело самим-то налабать.
Или, наконец, про то, как один скромный университет зачем-то захотел, чтобы grids не просто работали даже с клавиатурой, а ещё и с экранными читалками тоже, для слепых. Ну, это ж вообще любой школьник умеет, чего там делать-то.
Мог бы рассказать, но зачем? У вас уже всё солидно, Clarity хватает со всеми багами, значит всем остальным тоже должно хватать.
монструозный атавизм (ведь по-прежнему все свое — классы, разметка, билд системы и т.д)
Своя система классов, на порядок более богатая, существенно более вменяемая, чем ES6, а главное, работающая — это, безусловно, атавизм. Нынче в моде псевдо-недофичи, которые бабушки из TC39 писями на воде виляют, приговаривают: то ли примем, то ли нет, транспилятор на обед, вот те grunt, а вот webpack, не сойти б с ума никак.
И да, я много работал с ним и знаком с их прекраснейшими и супер-функциональными компонентами.
Наверное, недостаточно знакомы. Я вот сколько ни смотрю на все эти ангуляры и реакты, так грустно становится, туфта на постном масле. :( Виджеты если и есть, то до того убогие, аж оторопь берёт. На grids без кровавых слёз не взглянешь. В Clarity Dataview чуть потыкал, с десяток багов нашёл. Они вообще тестируют эти поделки хоть как-нибудь?
Вот не флейма ради, а просвещенья для, где вы берёте годный grid с поддержкой редактирования данных, валидации ввода и data binding для Vue или Angular?
Не ОП, но рискну предположить, что сам вид этой дикой белибердической смеси псевдо-JavaScript с псевдо-HTML вызывает рвотные позывы у людей, чьё чувство прекрасного не забито в кровавую тряпочку годами самобичевания с PHP?
далеко не везде есть нормальная навигация с клавиатуры, tabindex, ARIA-фичи и т.п.
Вообще нигде нет. Dojo 1 пыталось быть сколько-нибудь доступным, но ниасилило, а больше никто даже не пытался. Accessibility это очень трудно и больно, я вам как доктор говорю. :(
Это спорный момент, стоит ли делать зависимости или дубли, здесь каждый сам решает для себя, как ему удобнее, и главное, как удобнее для проекта.
Если чутка покопаться, то никакой спорности в этом моменте нет. Разница между доступом к ресурсу и доступом к дублю в поведении: дубль ведёт себя так, как вам нужно. Нужно, чтобы давал правильный ответ — всегда даёт правильный, нужно, чтобы давал отказ — всегда даёт отказ. В отличие от внешних ресурсов, поведение которых по прошествии времени меняется неизбежно.
Многие, очень многие (подавляющее большинство?) разработчиков думают о тестах свысока с позиции текущего момента в разработке: работает/не работает прямо сейчас. Основная ценность же набора тестов, особенно юнит тестов, состоит в нахождении регрессий. И основная ценность дублирования состоит в обеспечении отсутствия ложных регрессий.
От лени всё это. "Да чего дублировать, и так же работает". Ну, сейчас работает. А когда через год или два администраторы базы устроят лёгкий рефакторинг и у вас UI сойдёт с ума на тестах, может уйти куча времени на разбор полётов и устранение проблем. И никто это не отловит заранее, потому что их тесты работают же, а ваши они не смотрят. ;)
Да, я про getopt в курсе, и для тикля есть подобные, просто в данном случае для 2-3 опций использование дополнительного пакета счёл не целесообразным :)
Лучше сразу использовать готовые модули, это хорошая привычка. Потом всё равно придётся переписывать, когда надо будет добавить ещё один параметр. :)
Тут набор данных строго регламентирован, лишнего не прилетит, если только не ошибки с порта.
а) ошибки из порта, б) ошибки в коде, ц) раз в год и незаряженное ружьё стреляет. Ошибки в коде легко могут возникнуть, если надо будет поменять формат CDR или вообще кто-нибудь решит приспособить ваш скрипт для другой модели АТС. Да вы же сами и решите, потом когда-нибудь.
Если же взять за правило всегда использовать параметры SQL, то можно не думать о многих проблемах потом. Ещё одна хорошая привычка. :)
Мы перебираем список «for k in q_keys» и из его элементов преобразованных в строку «str(k)» лепим опять же строку с разделителем ", ".
Всё правильно, но обратите внимание — всё это используется для того, чтобы построить список полей для вставки и список позиционных параметров. Сами значения передаются в execute(), что и обеспечивает отсутствие проблем с некорректными значениями.
Вообще насколько я понимаю, в вашем случае приводить тип через str() не обязательно, поскольку ключи и так строки, но Python странный язык и допускает ключи других типов, числовые например. Поэтому я перестраховался, чтобы потом не ломать голову над странными ошибками. :)
Но для меня АКБ в ноуте скорее аналог UPS для всяких форс-мажоров, чем средство длительной автономной работы.
Это вам сейчас так кажется. А когда придётся с этой 17" дурой потаскаться денёк-другой по аэропортам с пересадками, то понимаешь, что этот лишний килограмм нафиг не нужен. И что этот 17" экран для нормальной стационарной работы всё равно слишком мал, а вот в самолёте уже слишком велик — на откидной столик не поставишь, упирается. И что батарейку выжирает слишком быстро, даже если на минимум подсветки поставить и тупо смотреть в код всё время.
Ну, т.е. я таскаюсь конечно, куда деваться. Новый лаптоп покупать жаба давит, этот ещё не сносил. Но 17" покупать точно не стал бы даже при наличии.
IMO оптимальный выбор — 15" + внешний дисплей (два). Или даже 13".
Склеивать строку запроса из ключей вместе со значениями не очень хорошая идея. В вашем случае SQL инъекции можно не бояться, но если вдруг на входе прилетит лишняя запятая или кавычка, то запрос сломается и вы об этом даже не узнаете.
Лучше использовать параметры SQL запроса:
conn.execute("INSERT INTO `foo` (foo, bar) VALUES (?, ?)", (foo_value, bar_value))
А чтобы сформировать сам запрос, циклы тоже использовать не обязательно. Можно оперировать списками:
q_keys = kwargs.keys()
q_values = kwargs.values()
q_key_list = ", ".join([str(k) for k in q_keys]
q_placeholder_list = ", ".join(['?' for k in q_keys])
query = "INSERT INTO `cdr` (%s) VALUES (%s)" % (q_key_list, q_placeholder_list)
connection.execute(query, q_values)
Этот подход даёт сразу несколько преимуществ: во-первых, по определению нет никаких лишних запятых в конце склеенной строки, во-вторых, можно не беспокоиться о кавычках и запятых внутри значений.
Кроме собственно кода, я бы ещё добавил как минимум индексы к таблице, ротацию логов и хотя бы рудиментарную обработку ошибок. Поскольку у вас CentOS 7, можно просто добавить systemd unit и получить две последние плюшки практически безвозмездно. :)
Пока не сталкивался с невозможностью использования нотивных тегов и пр., что радует безмерно))
Это просто у вас пока не было таких задач. Я бы с удовольствием использовал только нативные теги везде, но даже с банальными кнопками это не прокатывает. А такие штуки, как поля тегов или таблицы с отдельными регионами прокрутки в HTML вообще не вписываются никак, поэтому только WAI-ARIA, только хардкор.
Orca, в чем ее безмерный плюс, предоставляет как можно больше информации о позиции элемента, то есть если меню горизонтальное, то и читаться оно будет как горизонтальное.
Вот это интересно. Я всегда предполагал, что экранные читалки не озвучивают ориентацию меню просто потому, что она семантически неважна. Что в горизонтальном, что в вертикальном меню можно использовать одни и те же клавиши для навигации. Если вам важно знать ориентацию меню, то может быть имеет смысл открыть тикет в NVDA?
Не надо утрировать, вы же прекрасно понимаете, что я имел в виду. Для эксплуатации в условиях боевых действий есть отдельная категория решений, мы их тут не обсуждаем.
А падение пережил не один макбук, и не одно падение, и не только у меня. И не только падения, много чего. Алюминиевый корпус даёт много преимуществ, с этим тоже спорить будете? :)
Кстати, в вышеописанном случае падения лаптоп отлично проснулся, когда я его с трепетом открыл, чтобы оценить ущерб. И работал дальше с подключенным внешним дисплеем и клавиатурой, что дало мне возможность спокойно завершить работу на объекте в тот же день.
Тут вот ниже товарищи очень любят сравнивать Макбуки с Мерседесами, мол, дорого и ненужно. Аналогия хорошая, но не совсем верная: MacBook Pro это не седан S Klasse, это скорее микроавтобус Мерседес. Да, цена у них существенно выше Газелей, но почему-то Газелей всё меньше и меньше на дорогах, а Мерседесов и прочих Рено-Пежо всё больше. Тому объяснение есть и простое: время — деньги. Выше надёжность == меньше простоя == больше денег. :)
Имеете ввиду просто перевод Wcag или еще с проверкой на актуальность?
Не совсем понял вопрос. Насколько я знаю, все критерии, перечисленные в WCAG 2.0 вполне актуальны в принципе, но не все могут относиться к незрячим людям.
Это да, но не все ведь об этом знают?)
Знают наверное только те, кто уже разбил на этом лоб. :)
И вы, как профессионал в этом деле, можете объяснить мне смысл замены всех дефолтных тегов ролями?
Роли не заменяют нативные элементы. Роли и прочие WAI-ARIA атрибуты нужно использовать в тех случаях, когда нативный элемент по каким-то причинам использовать нельзя, или элемент используется не по своей основной роли.
Если вы в разметке используете <button>foo</button>, то никаких дополнительных атрибутов использовать не нужно. Если у вас кнопки сделаны через <div>foo</div>, то нужно использовать role="button" и пр., чтобы "переубедить" браузер и дать ему понять, что это кнопка, а не просто кусок разметки с текстом.
Казалось бы, почему просто не использовать элемент <button>? Тому есть разные веские причины, в т.ч. трудности со стилизацией, разница в поведении вне/внутри форм, разница в поведении на десктопе и планшетах/телефонах, различные глюки браузеров и т.д. и т.п. до тошноты. А если использовать не <button>, то лезут проблемы с доступностью.
Тут недостатки тоже есть, но меньшие, чем в случае использования <div role="button">. По крайней мере можно назначить обработчик на событие click и не заморачиваться отдельно на pointer*, touch*, key*; ну и отработка фокусирования тоже идёт нативная, без страшных извращений.
И это просто кнопка, да. Мы с вами ещё не добрались даже до кнопок с меню, split buttons, cycle buttons, segmented buttons… А теперь масштабируйте всё это до более сложных компонентов, типа Combobox или, боже упаси, Grid. :)
С Orca, например, вариант из WAI-ARIA активировать нельзя, то есть это бессмысленно как минимум для одной части программ экранного доступа.
Orca никогда не тестировал, мы поддерживаем только NVDA и JAWS. Но охотно верю, т.к. поддержка Accessibility API хромает во всех читалках, так же как и поддержка WAI-ARIA в браузерах. Хорошо хоть ребята из Mozilla слушают (иногда) и фиксят проблемы.
ASUS g74sx — может быть не семь лет, чуть меньше, но вот он сейчас передо мной стоит и ничего, всё ещё мощнее моего современного компа на работе
Это скорее говорит о том, что у вас на работе слабое железо. Что в общем и нормально, не всем нужны рабочие станции.
Ах да, на момент покупки был почти в 2 раза дешевле макбук про.
И все вышеперечисленные условия пережил, включая падения и прочие измывательства? Ну честно, не верю. Аргументы в стиле "а не надо ронять!" не принимаются. При выездах на объекты случаются разные казусы, а время == деньги, некогда с лаптопа пылинки сдувать.
Но самое главное: ваш пример совершенно не противоречит моему. Я не говорил, что нельзя найти работоспособное железо дешевле. Можно, современные компьютеры вообще парадоксально надёжны для своей сложности. Но разница между "наверное будет работать" и "точно будет работать, несмотря ни на что" есть и она стоит денег. Если ваше время стоит недёшево, то цена железок Apple оказывается вполне оправданной.
Я не monkey patching имел в виду, а читабельность кода. Когда что-то не получается или не знаешь, как сделать, весьма ценно бывает залезть в исходники фреймворка и посмотреть, как сделано то или это. Частенько и находишь, какую настройку подвинтить.
Ext JS далеко не идеален, но даже в 2011 читался существенно лучше, чем многие конкуренты по цеху. А с тех пор чуть-чуть улучшился. :)
Багов в них тоже нет, чтобы не было необходимости патчить?
Это как раз попытка выехать на тренде и заработать денег.
Я Ext JS имел в виду. Сам не большой фанат Cmd, но этот инструмент тоже легко недооценить. С первого взгляда это кривая и архаичная поделка для склеивания JavaScript файлов, но на самом деле Cmd умеет очень много разных интересных штук. Например, запускать тестовые сессии через WebDriver, с параллелизацией, очерёдностью, сбором статистики, свистелкам и перделками. ~500,000 юнит-тестов за полчаса, и так на каждый pull request. Просто для справки. :)
Вообще ни при чём, кроме того, что многие организации до сих пор Windows 7 используют и IE11. И модернизироваться не собираются. А некоторые даже за поддержку Windows XP и IE8 платят, дураки несолидные.
Ну, вам-то там в воображаемом мире конечно недосуг во все такие мелочи вникать. У вас там бабочки порхают, единороги прыгают, и все юзеры только пальчиками в айфоны последней модели тыкают.
Мне всё равно, кто что не умеет. Я отвечал на вопрос: а чем таким плохая, негодная, архаичная классовая система Ext JS может быть лучше модной, годной, молодёжной ES6. Спрашивали? Отвечаем.
Подобия достигайте, ваше дело. Тестами закрыть не забудьте только, а то открытий чудных много предстоит вам. Опять же из опыта говорю.
Условные тоже, и декларативно? Приведите примеры, если не сложно.
Да простые, типа таких:
onBeforeClassCreated,onClassExtended, etc. Чем они могут оказаться полезны, объяснить или сами догадаетесь?Да вот такой, простой. Класс Foo зависит от класса Bar, и использует Qux. При загрузке класс Foo не создаётся, пока не загрузятся Bar и Qux, со всеми своими зависимостями.
И в динамическом языке, ага. Работает уже лет 8 как. И инструментарием поддерживается для сборки. А вы дальше там простыни
import-ов ручками пишите, удачи.Статические свойства классов. Вы давайте, приводите примеры в ES6, не стесняйтесь. Я-то свои слова подкрепить могу в любой момент, зря что ли этот кусок перелопачивал и тестами закрывал. :P
Но ведь, что интересно, удавалось же? Я помню, как примерно в те же года пытался разобраться в Dojo. Вот уж где спагетти было жестокое. После него Ext JS 4 при всей своей лютой, бешеной глючности казался всё же глотком свежего воздуха.
С тех пор чуток воды утекло. Вы считаете нормальным сравнивать фреймворк 6-летней давности с современными решениями?
А у меня вот наоборот: сколько ни смотрю на этот "современный фронтент-стек", столько и плакать хочется. Избалован доступом к хорошим инструментам, чего уж там. :(
Сейчас как раз пытаюсь потихоньку выбрать, на чём делать новый личный проект. Ext JS использовать очень не хочется по личным причинам, но всё остальное даже рядом не валялось. Хоть всё бросай и начинай свой фреймворк, с блекджеком и прочими штуками...
При всём заочном уважении, есть мнение, что мсье не знает, о чём говорит. От слова "чуть более, чем полностью". И всё.
Кое-как работают, там, где они есть. В IE11 есть? Ой, нет. А что умеют? Ой, почти ничего не умеют. Mixins умеют? Нет. Overrides умеют? Нет. Hooks умеют? Нет. Dependency resolution умеют? Нет. Господи, ну хоть статические свойства классов-то умеют? Неа, всё ручками. Пилите, Шура, пилите...
Вообще очень печально, если вы не можете понять разницу между решениями хайпо-модно-молодёжными и реально полезными. Впрочем, это не только ваша проблема, это общая головная боль по больной на голову индустрии.
Чем конкретно крут webpack? По пунктам, если не трудно; бонусные баллы за объективное сравнение с другими решениями. Подозреваю, что дальше "webpack крут, потому что его Angular же использует!" вы не уйдёте.
Да чего ж не верить? Верю. Печально, что кроме библиотеки виджетов вы ничего не заметили или не оценили.
Вы мне сейчас напоминаете этот бородатый анекдот про солидную компанию с богатой историей, которая наймёт на пол-ставки студентов на подработку. Обещаем доширак сильно не задерживать!
У нас с вами очень разные понятия о полноценности таких интересных компонентов, как grids. И об уровне допустимого качества, очевидно, тоже. И даже, рискну предположить, "сёрьезность" компаний мы воспринимаем весьма по-разному; хотя, на мой взгляд, тут дело скорее в задачах, нежели в компаниях.
Я бы мог много разных примеров из опыта привести, скажем про одного несолидного немецкого производителя люксовых авто, которому приспичило запихнуть навигацию/просмотр/редактирование базы из ~9 млрд парт-номеров запчастей в один TreeGrid. С "бесконечной" прокруткой, страничной подкачкой по запросу и прочими весёлыми штуками. Ну, вот дураки там сидят, не осилили сами-то запилить.
Или про один забавный и крайне несолидный НИИ в Швейцарии, который там коллайдеры всякие гоняет туда-сюда, а данных-то с них 100500 терабайт или что-то такое. Визуализировать надо, для обработки и анализа. Тоже идиоты, ха-ха, да плёвое ж дело самим-то налабать.
Или, наконец, про то, как один скромный университет зачем-то захотел, чтобы grids не просто работали даже с клавиатурой, а ещё и с экранными читалками тоже, для слепых. Ну, это ж вообще любой школьник умеет, чего там делать-то.
Мог бы рассказать, но зачем? У вас уже всё солидно, Clarity хватает со всеми багами, значит всем остальным тоже должно хватать.
Цитируя любимую поговорку моей маман: Если вас ударят в глаз, вы, конечно, вскрикнете. Раз ударят, два ударят, а потом привыкнете.
Ну, или можете не мучиться. Ваш выбор.
Своя система классов, на порядок более богатая, существенно более вменяемая, чем ES6, а главное, работающая — это, безусловно, атавизм. Нынче в моде псевдо-недофичи, которые бабушки из TC39 писями на воде виляют, приговаривают: то ли примем, то ли нет, транспилятор на обед, вот те grunt, а вот webpack, не сойти б с ума никак.
Наверное, недостаточно знакомы. Я вот сколько ни смотрю на все эти ангуляры и реакты, так грустно становится, туфта на постном масле. :( Виджеты если и есть, то до того убогие, аж оторопь берёт. На grids без кровавых слёз не взглянешь. В Clarity Dataview чуть потыкал, с десяток багов нашёл. Они вообще тестируют эти поделки хоть как-нибудь?
Вот не флейма ради, а просвещенья для, где вы берёте годный grid с поддержкой редактирования данных, валидации ввода и data binding для Vue или Angular?
Не ОП, но рискну предположить, что сам вид этой дикой белибердической смеси псевдо-JavaScript с псевдо-HTML вызывает рвотные позывы у людей, чьё чувство прекрасного не забито в кровавую тряпочку годами самобичевания с PHP?
Вообще нигде нет. Dojo 1 пыталось быть сколько-нибудь доступным, но ниасилило, а больше никто даже не пытался. Accessibility это очень трудно и больно, я вам как доктор говорю. :(
а) Используйте нативные HTML элементы по максимуму,
б) Старайтесь выдерживать критерии WCAG 2.0
В общем, для простых сайтов это всё. В сложных приложениях семантика HTML начинает сбоить, там отдельный набор косяков и грабель.
Если чутка покопаться, то никакой спорности в этом моменте нет. Разница между доступом к ресурсу и доступом к дублю в поведении: дубль ведёт себя так, как вам нужно. Нужно, чтобы давал правильный ответ — всегда даёт правильный, нужно, чтобы давал отказ — всегда даёт отказ. В отличие от внешних ресурсов, поведение которых по прошествии времени меняется неизбежно.
Многие, очень многие (подавляющее большинство?) разработчиков думают о тестах
свысокас позиции текущего момента в разработке: работает/не работает прямо сейчас. Основная ценность же набора тестов, особенно юнит тестов, состоит в нахождении регрессий. И основная ценность дублирования состоит в обеспечении отсутствия ложных регрессий.От лени всё это. "Да чего дублировать, и так же работает". Ну, сейчас работает. А когда через год или два администраторы базы устроят лёгкий рефакторинг и у вас UI сойдёт с ума на тестах, может уйти куча времени на разбор полётов и устранение проблем. И никто это не отловит заранее, потому что их тесты работают же, а ваши они не смотрят. ;)
Тогда и спорить не буду, на вкус и цвет...
Зачем HDMI? Все современные MB Pro умеют Thunderbolt и тянут 2 дисплея цепочкой. Или 3, не помню.
Лучше сразу использовать готовые модули, это хорошая привычка. Потом всё равно придётся переписывать, когда надо будет добавить ещё один параметр. :)
а) ошибки из порта, б) ошибки в коде, ц) раз в год и незаряженное ружьё стреляет. Ошибки в коде легко могут возникнуть, если надо будет поменять формат CDR или вообще кто-нибудь решит приспособить ваш скрипт для другой модели АТС. Да вы же сами и решите, потом когда-нибудь.
Если же взять за правило всегда использовать параметры SQL, то можно не думать о многих проблемах потом. Ещё одна хорошая привычка. :)
Всё правильно, но обратите внимание — всё это используется для того, чтобы построить список полей для вставки и список позиционных параметров. Сами значения передаются в
execute(), что и обеспечивает отсутствие проблем с некорректными значениями.Вообще насколько я понимаю, в вашем случае приводить тип через
str()не обязательно, поскольку ключи и так строки, но Python странный язык и допускает ключи других типов, числовые например. Поэтому я перестраховался, чтобы потом не ломать голову над странными ошибками. :)Спасибо, никогда не думал о таких вариантах использования. Наверное всё же стоит попинать разработчиков NVDA, может хотя бы как опцию добавят.
Это вам сейчас так кажется. А когда придётся с этой 17" дурой потаскаться денёк-другой по аэропортам с пересадками, то понимаешь, что этот лишний килограмм нафиг не нужен. И что этот 17" экран для нормальной стационарной работы всё равно слишком мал, а вот в самолёте уже слишком велик — на откидной столик не поставишь, упирается. И что батарейку выжирает слишком быстро, даже если на минимум подсветки поставить и тупо смотреть в код всё время.
Ну, т.е. я таскаюсь конечно, куда деваться. Новый лаптоп покупать жаба давит, этот ещё не сносил. Но 17" покупать точно не стал бы даже при наличии.
IMO оптимальный выбор — 15" + внешний дисплей (два). Или даже 13".
Чуток конструктивной критики:
Я не знаю как в Tcl, но в Python для этого есть модуль getopt: https://docs.python.org/2/library/getopt.html
Разбор записей фиксированного формата проще и быстрее всего делается через unpack: https://docs.python.org/2/library/struct.html
Склеивать строку запроса из ключей вместе со значениями не очень хорошая идея. В вашем случае SQL инъекции можно не бояться, но если вдруг на входе прилетит лишняя запятая или кавычка, то запрос сломается и вы об этом даже не узнаете.
Лучше использовать параметры SQL запроса:
А чтобы сформировать сам запрос, циклы тоже использовать не обязательно. Можно оперировать списками:
Этот подход даёт сразу несколько преимуществ: во-первых, по определению нет никаких лишних запятых в конце склеенной строки, во-вторых, можно не беспокоиться о кавычках и запятых внутри значений.
Кроме собственно кода, я бы ещё добавил как минимум индексы к таблице, ротацию логов и хотя бы рудиментарную обработку ошибок. Поскольку у вас CentOS 7, можно просто добавить systemd unit и получить две последние плюшки практически безвозмездно. :)
Это просто у вас пока не было таких задач. Я бы с удовольствием использовал только нативные теги везде, но даже с банальными кнопками это не прокатывает. А такие штуки, как поля тегов или таблицы с отдельными регионами прокрутки в HTML вообще не вписываются никак, поэтому только WAI-ARIA, только хардкор.
Вот это интересно. Я всегда предполагал, что экранные читалки не озвучивают ориентацию меню просто потому, что она семантически неважна. Что в горизонтальном, что в вертикальном меню можно использовать одни и те же клавиши для навигации. Если вам важно знать ориентацию меню, то может быть имеет смысл открыть тикет в NVDA?
Не надо утрировать, вы же прекрасно понимаете, что я имел в виду. Для эксплуатации в условиях боевых действий есть отдельная категория решений, мы их тут не обсуждаем.
А падение пережил не один макбук, и не одно падение, и не только у меня. И не только падения, много чего. Алюминиевый корпус даёт много преимуществ, с этим тоже спорить будете? :)
Кстати, в вышеописанном случае падения лаптоп отлично проснулся, когда я его с трепетом открыл, чтобы оценить ущерб. И работал дальше с подключенным внешним дисплеем и клавиатурой, что дало мне возможность спокойно завершить работу на объекте в тот же день.
Тут вот ниже товарищи очень любят сравнивать Макбуки с Мерседесами, мол, дорого и ненужно. Аналогия хорошая, но не совсем верная: MacBook Pro это не седан S Klasse, это скорее микроавтобус Мерседес. Да, цена у них существенно выше Газелей, но почему-то Газелей всё меньше и меньше на дорогах, а Мерседесов и прочих Рено-Пежо всё больше. Тому объяснение есть и простое: время — деньги. Выше надёжность == меньше простоя == больше денег. :)
Не совсем понял вопрос. Насколько я знаю, все критерии, перечисленные в WCAG 2.0 вполне актуальны в принципе, но не все могут относиться к незрячим людям.
Знают наверное только те, кто уже разбил на этом лоб. :)
Роли не заменяют нативные элементы. Роли и прочие WAI-ARIA атрибуты нужно использовать в тех случаях, когда нативный элемент по каким-то причинам использовать нельзя, или элемент используется не по своей основной роли.
Если вы в разметке используете
<button>foo</button>, то никаких дополнительных атрибутов использовать не нужно. Если у вас кнопки сделаны через<div>foo</div>, то нужно использоватьrole="button"и пр., чтобы "переубедить" браузер и дать ему понять, что это кнопка, а не просто кусок разметки с текстом.Казалось бы, почему просто не использовать элемент
<button>? Тому есть разные веские причины, в т.ч. трудности со стилизацией, разница в поведении вне/внутри форм, разница в поведении на десктопе и планшетах/телефонах, различные глюки браузеров и т.д. и т.п. до тошноты. А если использовать не<button>, то лезут проблемы с доступностью.Текущий вариант решения примерно таков:
Тут недостатки тоже есть, но меньшие, чем в случае использования
<div role="button">. По крайней мере можно назначить обработчик на событие click и не заморачиваться отдельно наpointer*,touch*,key*; ну и отработка фокусирования тоже идёт нативная, безстрашныхизвращений.И это просто кнопка, да. Мы с вами ещё не добрались даже до кнопок с меню, split buttons, cycle buttons, segmented buttons… А теперь масштабируйте всё это до более сложных компонентов, типа Combobox или, боже упаси, Grid. :)
Orca никогда не тестировал, мы поддерживаем только NVDA и JAWS. Но охотно верю, т.к. поддержка Accessibility API хромает во всех читалках, так же как и поддержка WAI-ARIA в браузерах. Хорошо хоть ребята из Mozilla слушают (иногда) и фиксят проблемы.
Это скорее говорит о том, что у вас на работе слабое железо. Что в общем и нормально, не всем нужны рабочие станции.
И все вышеперечисленные условия пережил, включая падения и прочие измывательства? Ну честно, не верю. Аргументы в стиле "а не надо ронять!" не принимаются. При выездах на объекты случаются разные казусы, а время == деньги, некогда с лаптопа пылинки сдувать.
Но самое главное: ваш пример совершенно не противоречит моему. Я не говорил, что нельзя найти работоспособное железо дешевле. Можно, современные компьютеры вообще парадоксально надёжны для своей сложности. Но разница между "наверное будет работать" и "точно будет работать, несмотря ни на что" есть и она стоит денег. Если ваше время стоит недёшево, то цена железок Apple оказывается вполне оправданной.