![[syndicated profile]](https://www.dreamwidth.org/img/silk/identity/feed.png)
Релиз Miracle-WM v0.6.0
Под мощные фанфары к нам приехал новый релиз тайлового оконного менеджера/композитора для Wayland за авторством (преимущественно) Matthew Kosarek.
( читать дальше... )
Под мощные фанфары к нам приехал новый релиз тайлового оконного менеджера/композитора для Wayland за авторством (преимущественно) Matthew Kosarek.
( читать дальше... )
Доступен релиз операционной системы «Альт Виртуализация» 11.0. Сборка подготовлена на x86_64 и AArch64 Одиннадцатой платформы (ветка p11 Salvia), на базе ядра 6.12 (LTS).
( читать дальше... )
One of the endless struggles in writing reusable API endpoints is creating useful schemas to describe them. Each new serialization format comes up with new ways to express your constraints, each with their own quirks and footguns and absolute trainwrecks.
Maarten has the "pleasure" of consuming an XML-based API, provided by a third party. It comes with an XML schema, for validation. Now, the XML Schema Language has a large number of validators built in. For example, if you want to restrict a field to being a date, you can mark it's type as xsd:date
. This will enforce a YYYY-MM-DD
format on the data.
If you want to ruin that validation, you can do what the vendor did:
<xsd:simpleType name="DatumType">
<xsd:annotation>
<xsd:documentation>YYYY-MM-DD</xsd:documentation>
</xsd:annotation>
<xsd:restriction base="xsd:date">
<xsd:pattern value="(1|2)[0-9]{3}-(0|1)[0-9]-[0-3][0-9]" />
</xsd:restriction>
</xsd:simpleType>
You can see the xsd:pattern
element, which applies a regular expression to validation. And this regex will "validate" dates, excluding things which are definitely not dates, and allowing very valid dates, like February 31st, November 39th, and the 5th of Bureaucracy (the 18th month of the year), as 2025-02-31
, 2025-11-39
and 2025-18-05
are all valid strings according to the regex.
Now, an astute reader will note that this is a xsd:restriction
on a date; this means that it's applied in addition to ensuring the value is a valid date. So this idiocy is harmless. If you removed the xsd:pattern
element, the behavior would remain unchanged.
That leads us to a series of possible conclusions: either they don't understand how XML schema restrictions work, or they don't understand how dates work. As to which one applies, well, I'd say 1/3 chance they don't understand XML, 1/3 chance they don't understand dates, and a 1/3 chance they don't understand both.
Узнал на днях о существовании «Царь-рефрактора». Как известно, Царь-пушка никогда не стреляла, Царь-колокол никогда не звонил, а Царь-бомба, слава Богу, ни разу не применялась по назначению, лишь испытывалась. Так и Царь-рефрактор — вроде и стал крупнейшим за всю историю телескопом-рефрактором, но никакой научной пользы не принёс... Интересно? Ну, для начала — несколько вводных/просветительских слов :).
Каждому (надеюсь!), кто лишь имеет среднее школьное образование, должно быть известно, что основной инструмент астрономии — телескоп. Уже не все из даже более-менее продвинутых школьников знают, что, упрощая, телескопы по своей конструкции делятся на две группы: рефракторы (у них главным элементом, собирающим свет, является линза) и рефлекторы (они в качестве объектива используют зеркало); ну, понятно, что есть ещё и «комбинированные формы», сочетающие как линзы, так и зеркала, но всё равно что-то (либо линза, либо зеркало) будет являться главным элементом всей конструкции! Уже далеко не все земляне, а лишь более-менее интересующиеся астрономией, знают, что в случае с большими/серьёзными телескопами рефлекторы имеют множество преимуществ перед рефракторами. Самое очевидное из них заключается в том, что изготовить и поддерживать в недеформируемом (под действием собственного веса) состоянии зеркало большого размера заметно проще, нежели линзу аналогичных параметров. Ну, не буду говорить о куче других тонкостей, но поверьте на слово: уже более-менее в начале XX века стало ясно, что при дальнейшем наращивании апертуры (диаметра объектива) будущее однозначно принадлежит рефлекторам (пусть и с кучей дополнительных примочек).
Carolyn inherited a somewhat old project that had been initiated by a "rockstar" developer, and then passed to developer after developer over the years. They burned through rockstars faster than Spinal Tap goes through drummers. The result is gems like this:
private void init(){
ResourceHelper rh = new ResourceHelper();
for ( int i = 0; i < 12; i++) {
months[i] = rh.getResource("calendar."+monthkeys[i]+".long");
months_s[i] = rh.getResource("calendar."+monthkeys[i]+".short");
}
StaticData data = SomeService.current().getStaticData();
this.bankHolidayList = data.getBankHolidayList();
colors.put("#dddddd", "#dddddd");
colors.put("#cccccc", "#cccccc");
colors.put("#e6e6e6", "#e6e6e6");
colors.put("#ff0000", "#ffcccc");
colors.put("#ffff00", "#ffffcc");
colors.put("#00ff00", "#ccffcc");
colors.put("#5050ff", "#ccccff");
colors.put("#aa0000", "#ff9999");
colors.put("#ff8000", "#ffcc99");
colors.put("#99ff99", "#ccffcc");
colors.put("#ffcc99", "#ffffcc");
colors.put("#ff9966", "#ffcc99");
colors.put("#00c040", "#99cc99");
colors.put("#aadddd", "#ccffff");
colors.put("#e0e040", "#ffff99");
colors.put("#6699ff", "#99ccff");
}
There are plenty of things in this function that raise concerns- whatever is going on with the ResourceHelper
and the monthkeys
array, for example. But let's just breeze past that into that colors
lookup table, because boy oh boy.
There's the obvious issue of using server-side code to manage colors instead of CSS, which is bad, sure. But this translation table which converts some colors (presumably already used in the display?) to some other colors (presumably to replace the display colors) is downright mystifying. How did this happen? Why did this happen? What happens when we attempt to apply a color not in the lookup table?
I want to say more mean things about this, but the more I stare at the original colors and what they get translated to, I think this lookup table is trying to tell me I should…
…
…
lighten up.