Чтобы быстрее понять, о чём здесь идёт речь, советую почитать:
что такое виджеты,
чем они хороши
и каковы их перспективы.
Это сообщение показывается только один раз. Такие же ссылки вы можете найти в правой колонке, в блоке "Рекомендую прочесть"
Р
ешил я сейчас загрузить свежую версию гаджетов для Википедии, зешел на http://gallery.microsoft.com… и вместо галереи оказался на такой вот веселенькой странице с сообщением о том, что галерея «отправлена в отставку». Microsoft решила больше не поддерживать разработку и распространение гаджетов, чтобы «сконцентирироваться на поддержке более богатых возможностей новых версий Windows». Порыскав по сети, я обнаружил, что произошло это не так давно: в начале октября.
Гаджеты для Windows по-прежнему можно разрабатывать и устанавливать, но размещать их предлагается не в галерее, а на хостинге для разработчиков CodePlex. Что, как вы понимаете, совсем не так удобно для конечных пользователей.
То, что MS была не очень заинтересована в последние годы в гаджетах, чувствовалось: баги Sidebar не правились, корпоративный блог о гаджетах заглох. Так что закрытие галереи – вполне логичное продолжение. Вот почему плохо программисту связываться с проприетарными технологиями: решили перестать развивать – и всё, прости-прощай. Билл дал – Билл взял. Печально.
Ну а для тех, кто хочет всё-таки обновить гаджеты Википедии, я выложил новые версии у себя на сайте. В них исправлен, наконец, баг со счётчиком страниц, и гаджеты перенастроены на новую верстку Википедии.
Wikiknow.gadget
Wikiday.gadget
Комментировать (1)
Уф, наконец-то осилил «Рефакторинг» Мартина Фаулера.
Обычно я читаю в книге каждую строчку, включая введение, примечания и заключение, потому что если автор что-то написал, значит посчитал это важным. Но если бы поступил так с «Рефакторингом», закончил бы где-то к сентябрю: уж очень обстоятельно Фаулер описывает каждую мелочь. К счастью, где-то после середины я понял, что это справочник, а не учебник, поэтому нужно читать описание рефакторинга, мотивировку, и только если что-то показалось непонятным, углубляться в технику и разбор примеров. В результате вторую половину книги добил за неделю.
Впечатление.
Книжка, безусловно, полезная, но не для начинающих: теорию ООП и паттерны GoF желательно уже знать. Позволяет немного лучше понять, что происходит в голове крутых программистов. Если пропускать занудные куски, читается очень легко. Кое-какие огрехи в переводе всё-таки есть, но впечатление почти живого общения с умными людьми они не портят. Например, очень забавно наблюдать как Фаулер и Кент Бек (являющийся одним из соавторов) подшучивают друг над другом, в том числе в коде примеров. 
Я стараюсь по очереди читать книги из разных областей. Эта была про разработку ПО, поэтому на очереди либо что-то про управление/мышление, либо научно-популярное. Кстати, вам было бы интересно, если бы я писал рецензии на научпоп в этот блог?
Что вы об этом думаете?
В моей профессиональной жизни был период, когда я вообще не читал книг по разработке. Казалось, что учебники по технологиям уже прочитаны, всё что нужно для работы я знаю, а остальное можно вытащить из мануалов и постов на Хабре, и то имеет смысл заниматься этим, только когда понадобится. Причём, судя по разговорам с коллегами, такое настроение возникает у многих. Потом я понял, насколько заблуждался, и даже немного пожалел об упущенном времени.
В один прекрасный день меня настигло-таки ощущение, что я не знаю многих, в том числе базовых для работы вещей, и я набросился на учебу, за полгода проглотив больше книг, чем за предыдущие два. Процесс продолжается до сих пор с переменной скоростью. Есть книги, которые осиливаешь на одном дыхании, а есть те, на которых застреваешь и приходится себя разными способами заставлять дойти до конца.
В этом посте я приведу небольшие рецензии на несколько технических книжек.
С. Макконнелл, «Совершенный код. Мастер-класс»
Тотальный и безусловный мастрид для человека, который хочет называть себя разработчиком. Эту книгу папы-программисты должны читать на ночь детям программистам. Идет очень легко, даром что толстая: хороший перевод, приятный язык. Единственный минус – сложно носить с собой в метро (у меня она занимала всю сумку).
Там есть все: от того, как называть переменные, до организации процесса разработки. Всё рассказано подробно и приближенно к практике, есть огромное количество ссылок на материалы для дальнейшего изучения. В общем, эту книгу я крайне рекомендую.
Э. Хант, Д. Томас, «Программист-прагматик. Путь от подмастерья к мастеру»
Это такой «Макконнелл для ленивых». Она гораздо меньше и часть материала повторяется. Писалась, похоже, раньше, поэтому часть упоминаемых в ней технологий устврели.
Если «Совершенный код» вас уж очень пугает размером, попробуйте её. Если СК прочли, не тратьте время.
Э. Гамма, Р. Хелм, Р. Джонсон, Дж. Влиссидес, «Приемы объектно-ориентированного проектирования. Паттерны проектирования»
Классика. Если вы хотите вставлять в резюме слово «паттерны», обязательно её прочтите, а то потом не сможете рассказать, чем декоратор отличается от заместителя, и будете выглядеть глупо.
Книжка мне показалась тяжелой: в неё надо «въезжать» и думать
почти на каждой странице. Зато потом всё в голове выстраивается в очень красивую картину, стоящую затраченных усилий.
При изучении паттернов основная проблема – они быстро забываются. Поэтому, чтобы закрепить знания, когда прочли про какой-то паттерн, подумайте, как его можно было бы применить на практике в ваших проектах.
Крэг Ларман, «Применение UML 2.0 и шаблонов проектирования»
Очень просветляющая книга. Несмотря на название, она не только про UML и паттерны (кстати, паттерны – не те, что у GoF, а более общие, GRASP). Как исследовать предметную область, как выделять её объекты и переносить их в код, как организовать процесс проектирования и разработки – все там.
Написана приятно, я прочел на одном дыхании (хотя кое-кто из коллег этого впечатления не разделяет), утыкав страницы разноцветными закладками.
Советую её каждому, кто хочет спроектировать и разработать что-то сложнее гостевой книги.
Марк Арнольд, Джефф Д. Алмейда, Клинт Миллер, «Администрирование Apache»
Единственная книга на русском по администрированию веб-серверов, которую я нашел в продаже (сейчас, похоже, и она пропала). И это её главное достоинство, дальше идут недостатки: отвратительный перевод, устаревший материал (она про Apache 1.3).
Сейчас читаю, идет тяжело. Конечно, она дает более-менее целостное представление о веб-сервере, которое трудно получить чтением мануалов, но сил для этого приходится тратить много.
В моем списке для чтения еще много позиций, так что продолжение следует.
А какие книги для разработчиков можете порекомендовать вы?
Комментировать (2)
Замечательное (и очень точное) описание того, что чувствует человек, впервые становясь из подчиненного начальником.
Что вы об этом думаете?
С приходом вебдванольности, облаками тегов стали щеголять чуть ли не все сайты, вплоть до домашних страничек аквариумных рыбок. Но на мой взгляд, теги – вообще не такой уж удобный способ разбиения контента по категориям, а уж облако тегов – ужасно неудобная штука для организации навигации.
Почему?
Теги, чаще всего, проставляются неправильно.
По идее, в тегах должны быть некие ключевые слова, полно и точно описывающие обсуждаемый в статье материал. Для того чтобы выделить такие слова (обеспечить точность), нужно провести анализ написанной статьи или с самого начала иметь чёткое представление о том, что в ней будет. Увы, мало кто заморачивается с выделением основных мыслей, а уж заботиться о полноте набора тегов (включая слова-ассоциации) тем более мало какой автор захочет.
Одно и то же понятие-тег может быть записано по-разному.
Например, этот пост мог бы быть помечен как «тег», «теги», «тегирование» или ещё 10 вариантов одного и того же слова. Такие пачки нужно как-то объединять. Либо этим должен заниматься автор (которому дополнительная работа не нужна), либо отдельный модератор словаря тегов (у ВКонтакте, как я слышал, есть такие модераторы для справочников городов/школ), либо хитроумная автоматическая система (которой, тогда уж, проще скормить весь текст целиком для выделения ключевых слов).
Немного спасает автодополнение при вводе тегов, но и оно – не панацея.
Облако тегов неудобно просматривать.
Оно дает понятие о том, какие теги являются наиболее популярными, но при этом не помогает пользователю найти материал на тему, которая его интересует. Тег этой темы может показываться маленькими буквами, а может вообще быть исключен из облака (как правило, оно ограничено по количеству слов).
Плюс даже если пользователь знает, что слово есть в облаке, найти его в этом месиве сложно: да, слова обычно отсортированы по алфавиту, но разница в высоте букв делает сортировку бессмысленной.
Для чего же полезны теги?
- Насколько я знаю, в целях поисковой оптимизации их хорошо использовать для внутренней перелинковки страниц.
- Для разделения по категориям контента, по которому нельзя провести полнотекстовый поиск (например, изображений или видео).
- Также по ним можно смотреть статистику популярности неких понятий у авторов постов.
Соответственно, вот, какой должна быть идеальная система тегирования, с моей точки зрения.
- Теги должны проставляться автоматически (или полуавтоматически, но с контролем синонимов) на основе текста статьи.
- Поисковым роботам и новым пользователям облако тегов должно показываться так, как показывается сейчас.
- А каждому «постоянному» пользователю должно показываться индивидуальное облако, учитывающее то, интерес к каким темам он проявляет. Условно говоря, если человек посмотрел 10 статей с тегом PHP и 5 с тегом Apache, то тег «PHP» должен быть в 2 раза больше тега «Apache». Конечно, когда дело дойдёт до реализации конкретных алгоритмов, простор для творчества будет большой, ведь при таком подходе облако тегов превращается в рекомендательную систему.
А вы сами часто пользуетесь тегами на сайтах?
Комментировать (8)
