All streams
Search
Write a publication
Pull to refresh
34
0.2
ionicman @ionicman

User

Send message
Как много споров то и рассуждений :)

Нет там ни правых ни виноватых.

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

А я надеюсь что это положительно скажется как на MS IE, так и на MZ FF так и на Опере.

А в конечном счете это выгодно нам — простым смертным ;) и я надеюсь что победим именно мы )
Ужас какой…
А если компиллер изменит порядок генерациии… ии… вообще страшно :D
из цикла #define true false
:-D

Огромное спасибо!
Давно не программил на плюсах и начинаю уже забывать важные нюансы. Было очень приятно почитать вашу отлично оформленную и грамотно написанную статью ( особенно спс за примеры — так очень быстро вникаешь ) и освежить свою память.

Примного благодарю!
идея вполне ничего, но мне кажется вполне логичным было бы показывать всего две вещи — что нажат капс, и что язык отличен от английского.
Согласитесь, что 99.9% паролей — это всежтаки латиница, а если вы наберете 123 или ;. на русской, китайской или же корейской раскладке — ничего от этого не изменится.

И выводить это как тултип со сноской ( типо как в вики на внешние ссылки — т.е. типа облачка такого с указателем ) а в ней писать нажат CASP LOCK, введены нелатинские символы. ну либо пиктограммками справа.
-Чем занимаешься?
-Да вот пытаюсь скрестить мондавошку со светлячком!
-Зачем?
-А прикинь — снимаешь трусы — а там Лас Вегас :-D
Пример из статьи — синетика. Редко ктото такое делает разделение на страницы внутри xslt, а вот для того чтобы научится ДУМАТЬ на нем — вполне подходящая тема.
это не аргументы, это «it depends» ;)
да, и на нем не пишут программы — милости прошу в вики прочесть что такое xslt ;) Хотя конечно программы на чему кгодно можно писать при наличае определнного вида извращенности ) Для программа — да, увы и ах — громоздко, тормознуто и черзжопно. Но както не есть хорошо писать программы на языке для потокового парсинга :) Вы же не ездите на машине с квадртаными колесами — ксттаи ездить будет… но както тормознуто и черезжопно ;)
я не знаю, что там у вас длинее в 1.5 раза ))) но язык реально удобный и хороший. если против — прошу аргументы ;)
производительность весьма на достойном уровне, чтобы она начала беспокоить — надо иметь определнную задачу ))) Обычно все упирается далеко не в парсер, а в БД например ;)
Вот я так отвечу на всю эту союачью радость — попробуйте писать на XSLT, поприменять его в практике. Более лаконичного и простого языка для создания мощного и одновременно с ним простого шаблонизатора Вы врядли найдете.
Опыт у меня разработки на XSLT — 2 года — и язык этот устраивает всем. Некоторые конструкйии несколько громоздки типа choose — но поверьте — это очень маленький минус по сравнению с массой плюсов.

А когда работаешь с удобным инструментом — как то абсолютно пофигу худший он или лучший из языков функционального программирования ;)
По поводу флешек с защитой от записи — есть просто вариант — купить Kingstone MobileLite Card Reader Как выглядит — стоит дешево, достаточно распространен.

Купить к нему sd карту нужного вам объема и типа с переключателем защиты записи.

Вы получаете картридер, читающий SD & SDHC & MiniSD & MicroSD — небольшого размера, всегда можно утащить с собой — очень полезнач весч в принципе для айтишника ( ну там карточку с фотографиями например с фотоаппарата скинуть на комп красивой девушке, которая просит — типа нет шнурка от фотика — а его практически всегда нет, и т.д. :-) )

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

В случае NTFS и форматирования флешки — всежтаки лучше создать autorun и защитить его от записи.
Может если уж делать, то делать так:
1. Сервер Бизнес логики:
БД + реализация бизнесЛогики
Работа через обмен данными XML

2. Сервер ренедринга ( представления )
Обмен с [1] по XML, с клиентами — чем угодно, в случае с web — HTML / CSS / JS

Плюсы такой технологии:
1) возможности кластеризации серверов бизнес логики, либо разделения их по функционалу
2) возможность кластеризации серверов рендеринга, либо разделения их по функционалу
3) возможность кэширования документов [2]
4) возможность использования разных реализаций [1] и [2], но работающих как единое целое.

А в данном случае вы получаете очень тяжоловесную систему, во первых получить один БОЛЬШОЙ файл гораздо быстрее и легче, чем обработать 10 мелких запросов ( а я боюсь что во время интенсивной работы их у Вас будет куда больше ), вы откзываетесь от легковесных клиентов, где далеко не всегда можно использовать JS — не есть хорошо. Вы зависимы от скорости выполнения клиентских JS, т.к. инасе работа с системой превратится в нудную тягомотину.

Увы и ах — не понятны цели — ЗАЧЕМ? чтобы было так красиво все? Далеко не всегда красивое решение — это лучшее решение. К сожелению.

P.S. Спс за топик — реально интересно было почитать.
Вполне. а тесты хранимками были или внешкой?
А для какого SQL, если не секрет? Я понимаю, что здесь универсально, я имею ввиду на каком испытывалос Вами?

У меня была задача сделать универсальное хранение сущностей — сделал аналогично. Потом на хранимках написал какое-то подобие API -т.е. addProp / remProp и т.д. В том числе и поиск. Делал на PgSQL.
Работало очень шустро, просто интересно как на других SQL-ях?

Кстати говоря на практике потом, как выяснилось — не очень нужно. Гораздо более простой и удобной оказалось использование вот такой штуки — каждый объект имел свою собственную таблицу со своими свойствами, была таблица, представлявшая собой связь «тип объекта» => «таблица объекта» ну и остальное все от этого плясало.

Возможно что изменение такой структуры более долгое, т.к. требует alter, но на практике, во всяком случае в моем варианте, это требовалось крайне редко.
Я бы, с удовольствием, но, к сожелению, здесь опубликовать не могу из-за кармы — люблю поспорить ;)

Может быть я какнидь опубликую статейку в блоге и выложу сюда ссылку, я думаю кол-во приверженцев возрастет в разы :)

Вообще XSLT обаладет инетересной чертой — стоит пглядеть на него — как какжется что он какой-то «угловатый» и ограниченный, но стоит его попробовать на реальном проекте, попробывать всю мощь XPath и осей — как бесконечно в него влюбляешься. Есть у него главная черта, которой очень мало в других языках ( не в обиду будет никому сказано ) — это его лаконичность.
Вот люблю я лаконичные языки вроде регспов и xslt, хотя иногда конечно эта лаконичность заставляет понапрягать мозг — ну дак так даже интереснее, тем более что всеж таки большинство шаттных проблем решаются вполне без напрягов, да и большинство шаблонизаторов поддерживают вызов процедур внешнего языка, если уж вообще никак.
Как практикующий сторонник XSLT сказал бы, но воздержусь ибо сторонка вроде не вмешивается… она просто стоит и работает ;)
Весьма спасибо, особенно за pydev — не натыкался. Благодарствую
Кстати ниже всего этого darkk очень неплохо написал о своем мнении.

Можете прочесть это, а потом перечитать свои топики.

Еще раз повторюсь — профессионал может считать, что какой-то инструмент не подходит лично ему по таким-то и таким-то пречинам. Он может это говорить ИМХО свое, но никогда не скажет что инструмент — гавно ;) darkk сказал что «мог бы сказать» но не сказал ;)

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

Кстати благодаря PHP движению возникло множество терок из которых потом и повылезали различные решения, принятые в дальнешем на вооружение. Вам не кажется, что только за одно это можно уважать данное сообщество, даже не используя его язык?
Isn'it?

Собственно спор дальше ниочем считаю бесмыссленым, я не призывал Вас полюбить чтото или начать писать на PHP, и не говорил что PHP — лучший язык ;)

Information

Rating
2,760-th
Registered
Activity