Не понимаю, я вас граждане — ни автора этой заметки, ни предыдущей: почему вы сразу начинаете писать исключительно собственные измышления. Ладно — писать, но публиковать-то зачем, если не разу не заглянули в официальную документацию?! В MSDN чётко написано, что soft links и symbolic links — разные сущности. Вы же сами таким фразочками:
с мягкими или символьными ссылками есть путаница. Так вот я далее буду говорить о тех символьных ссылках которые делаются программой Junction
путаницу только увеличиваете.
Более того: устоявшийся термин символические ссылки, а не символьные — именно так они упоминаются в справке Windows и огромном количестве литературы по Unix, Linux, Windows.
Что касается «фактов о не очевидном поведении этих ссылок» — поведение меняется в зависимости от версии Windows — о чём опять же на сайтах MS написано, даже с примерами:
Under Windows Server 2003, if you copy %systemroot%\SYSVOL, you do not copy the junction points. However, under Windows 2000, if you copy %systemroot%\SYSVOL, you do copy the junction points.
У вас даже не указано на какой XP вы экспериментировали: 32 или 64, какой SP.
А по сути вопроса — в случае приобретения коммерческой организацией, ведь ещё забавнее получается: коробочная версия облагается НДС — который можно предъявить к возврату. Т.е. фактически коробочная версия в ряде случаев получается заметно дешевле электронной.
Поставил по случаю релиза четвёрку — честно говоря, после стольких разговоров об интерфейсе, был удивлён такой средненькой стилизацией окна под Vista :-)
А не подскажут ли опытные скайповоды, как удалить недоставленное текстовое сообщение?
Вовсе они не одинаковы: на Vista Home Basic не поддерживается модный пользовательский интерфейс Aero Glas, поэтому требования к видео и памяти ниже; а Ultimate, к примеру, для реализации всех возможностей BitLocker нужен аппаратный криптографический модуль.
Описание плохое, потому что старое. В Vista и более поздних версиях Windows есть две разных сущности: directory junctions и symbolic link для директорий
От других сервисов надо перенимать лучшие стороны, а не бездумно копировать функционал. На счёт «терпеть не могу» — я лишь перефразировал вашу фразу, чтобы вам же продемонстрировать просто возможность существования других мнений. Не надо передёргивать — никто из других читателей не подумал, то мы (вы и я) оцениваем сайт по аватаркам.
Я не говорил, что нужно отказаться от других форматов в пользу png — я лишь пояснил вам, что jpeg — не панацея. Ну и прежде чем что-то утверждать — неплохо бы это проверить ;-) На NNM аватарки не только в jpeg; а текущая ситуация с аватарками на хабре — вообще отдельный разговор ;)
Я обычно рекомендую Gtalk или Я.Онлайн — начинать надо с простого. Тем более, у них много приятных мелочей. Когда начнёт явно недоставать каких-то возможностей, человек сам осознанно сравнит плюсы и минусы разных клиентов.
В любом случае: не ошибается тот, кто ничего не делает. Я пытался в нескольких строчках показать как можно упростить разработку, расширив применяемый синтаксис SQL. А что делали вы? ;)
Спасибо, я знаю что такое варез и где им можно разжиться ;-)
Что вы докопались до этой функции? ifnull запоминается на раз и гораздо точнее отображает суть процесса. Поэтому код с ним нагляднее. Признаю, в примере coalescue был бы уместнее чем два ifnull, зато пришлось бы ещё комментировать, а так — всё понятно без дополнительных объяснений.
Честно говоря, не слежу за эволюциями ANSI SQL по двум основным причинам:
1. Если брать серьёзные сервера БД — стандарт безбожно отстаёт от полезных и эффективных инноваций реальных разработок. Если брать массовые SQlite и MySQL (у многих хостеров ещё 4ая версия стоит) — то уже они отстают от актуальной версии стандарта. Т.е. толку от него как от «семиуровневой модели OSI» — чисто академический, т.е. слабо применимый на практике.
2. Он закрыт — почитать можно только за денежку.
Вьюха позволяет разработчику абстрагироваться от реализации — он просто знает, что в запросе к ней получит отображаемое имя автора, путь к аватарке (ещё какие-то основные данные), а из каких таблиц-полей это всё берётся на самом деле — не важно. Можно вносить изменения в БД не перелопачивая весь приложения.
ваша формулировка подразумевает лишнее обращение к БД каждый раз — я показал, что получение этой же информации из БД практически не требует никаких дополнительных телодвижений.
А я терпеть не могу сервисы, которые пережимают нормальные аватарки независимо от их размера и разрешения ;-) На самом деле — это ваша политика более жёсткая по отношению к пользователю. То что png будет больше чем jpeg — это заблуждение. В случае фотографии — да; но аватарки чаще рисованные — png получится меньше, качество картинки будет выше. Ваш способ менее универсален; более расточителен в плане ресурсов; не настолько дружественный для пользователя, как мог бы быть.
В данном конкретном случае, информация об аватарке так или иначе присутствует в таблице с пользовательским профилем — или явно указано имя файла; либо если в качестве имени используется ID пользователя, всё равно необходимо хранить тип изображения (jpeg, gif, png). На мой взгляд — «решение в лоб»: при отсутствии аватары оставлять в таблице неопределённое значение — NULL.
А в операторе выборки использовать ifnull:
select
nick_name, ifnull(avatar,'аватарка по умолчанию'), title, message
from users
inner join messages on users.id=messages.user_id
where 'условие выборки сообщений'
Точно так же можно «заполнить» другие поля: например, если не указан ник, показывать реальное имя, а если нет и его — логин:
select ifnull(nick_name,ifnull(real_name,login)), ... from ...
Если используется 5ый MySQL — лучше вообще создать представление (view) для выборки основных данных пользователя.
Не понял, как форма трубки принуждает к ношению запасных батареек ;-)
И почему трубка вообще должна быть плоской?! — далеко не самое эргономичное решение. Надо сначала этот Philips подержать в руке, может так ещё и удобнее. Хотя выглядит непривычно.
В MSDN чётко написано, что soft links и symbolic links — разные сущности. Вы же сами таким фразочками:путаницу только увеличиваете.
Более того: устоявшийся термин символические ссылки, а не символьные — именно так они упоминаются в справке Windows и огромном количестве литературы по Unix, Linux, Windows.
Что касается «фактов о не очевидном поведении этих ссылок» — поведение меняется в зависимости от версии Windows — о чём опять же на сайтах MS написано, даже с примерами:У вас даже не указано на какой XP вы экспериментировали: 32 или 64, какой SP.
А по сути вопроса — в случае приобретения коммерческой организацией, ведь ещё забавнее получается: коробочная версия облагается НДС — который можно предъявить к возврату. Т.е. фактически коробочная версия в ряде случаев получается заметно дешевле электронной.
А не подскажут ли опытные скайповоды, как удалить недоставленное текстовое сообщение?
Я не говорил, что нужно отказаться от других форматов в пользу png — я лишь пояснил вам, что jpeg — не панацея. Ну и прежде чем что-то утверждать — неплохо бы это проверить ;-) На NNM аватарки не только в jpeg; а текущая ситуация с аватарками на хабре — вообще отдельный разговор ;)
В любом случае: не ошибается тот, кто ничего не делает. Я пытался в нескольких строчках показать как можно упростить разработку, расширив применяемый синтаксис SQL. А что делали вы? ;)
Что вы докопались до этой функции? ifnull запоминается на раз и гораздо точнее отображает суть процесса. Поэтому код с ним нагляднее. Признаю, в примере coalescue был бы уместнее чем два ifnull, зато пришлось бы ещё комментировать, а так — всё понятно без дополнительных объяснений.
1. Если брать серьёзные сервера БД — стандарт безбожно отстаёт от полезных и эффективных инноваций реальных разработок. Если брать массовые SQlite и MySQL (у многих хостеров ещё 4ая версия стоит) — то уже они отстают от актуальной версии стандарта. Т.е. толку от него как от «семиуровневой модели OSI» — чисто академический, т.е. слабо применимый на практике.
2. Он закрыт — почитать можно только за денежку.
Вьюха позволяет разработчику абстрагироваться от реализации — он просто знает, что в запросе к ней получит отображаемое имя автора, путь к аватарке (ещё какие-то основные данные), а из каких таблиц-полей это всё берётся на самом деле — не важно. Можно вносить изменения в БД не перелопачивая весь приложения.
А я терпеть не могу сервисы, которые пережимают нормальные аватарки независимо от их размера и разрешения ;-) На самом деле — это ваша политика более жёсткая по отношению к пользователю. То что png будет больше чем jpeg — это заблуждение. В случае фотографии — да; но аватарки чаще рисованные — png получится меньше, качество картинки будет выше. Ваш способ менее универсален; более расточителен в плане ресурсов; не настолько дружественный для пользователя, как мог бы быть.
А в операторе выборки использовать ifnull:
select nick_name, ifnull(avatar,'аватарка по умолчанию'), title, message from users inner join messages on users.id=messages.user_id where 'условие выборки сообщений'Точно так же можно «заполнить» другие поля: например, если не указан ник, показывать реальное имя, а если нет и его — логин:Если используется 5ый MySQL — лучше вообще создать представление (view) для выборки основных данных пользователя.
И почему трубка вообще должна быть плоской?! — далеко не самое эргономичное решение. Надо сначала этот Philips подержать в руке, может так ещё и удобнее. Хотя выглядит непривычно.