Почти месяц назад вышла вторая версия прекрасного и замечательного jQuery Notification plugin для вывода самых разнообразных уведомлений на сайте, странно что Хабр вообще обошёл его стороной, исправлю ситуацию.

Вы уже попробовали пройти какой-нибудь онлайн-курс? Если еще нет — очень рекомендую. Сейчас можно получить неплохие знания от известных заведений (Stanford, Harvard, MIT, etc) совершенно безвозмездно, то есть даром. Если же Вы в числе тех счастливчиков, кто уже распробовал онлайн-курсы или вам интересно, как это бывает — прошу под кат. И сразу предупреждаю, внутри не будет очередной дискуссии про несовершество нашего образования.

(от 27 июля 2012)
При написании нативного веб-приложения легко начать чувствовать себя богом, способным работать просто с библиотекой работы с DOM (такой как jQuery) и горсткой сервисных плагинов. Вскоре возникает проблема в виде груды вложенных возвратных функций jQuery и разбросанных DOM-элементов без всякой структуры вместо приложения.

Короче, мы застреваем в спагетти-коде. К счастью, есть современные JS-фреймворки (библиотеки, задающие, кроме функций, правила организации кода --прим. перев.), помогающие поддерживать структуру и организованность в проекте, облегчающие ремонтопригодность в будущем.

■ Что такое MVC или, лучше сказать, MV*?

Эти современные библиотеки дают разработчикам простой путь к организации кода, используя вариации паттерна проектирования, известного как MVC (Model-View-Controller). MVC разделяет задачи в приложении на 3 части:

При написании приложений, одной из важнейших вопросов являются потребление памяти и отзывчивость (скорость работы).

Считается, что сборщик мусора – черный ящик, работу которого нельзя предугадать.

А еще говорят, что GC в .NET практически не настраиваемый. А еще, что нельзя посмотреть исходники как классов .NET Framework, так и CLR, GC и т.п.

А я скажу как бы ни так!

В данной статье мы рассмотрим:

• структура организации размещения объектов в памяти
• CLR 4.5 Background Server GC
• правильная настройка сборщика мусора
• эффективный апгрейд приложений до .NET 4.0+
• правильное ручное управление памятью

(Нет, на самом деле я в это не верю, но ведь неплохой заголовок получился, не так ли? DataSet’ы имеют право на существование, но только не в качестве внешних бизнес-объектов или контрактов Web-сервисов).

Это перевод оригинальной статьи Design Patterns: When Breaking The Rules Is OK

Принято считать, что все мы используем шаблоны проектирования при разработке общих веб-элементов. Нам прекрасно известно, какими должны быть внешний вид кнопок и их поведение, и мы владеем методами разработки веб-форм, связанных с этими кнопками.

И несмотря на всё это Интернет буквально наводнен некорректными веб-формами, кнопками, похожими на что угодно, но не на кнопки, и сбивающими с толку элементами навигации. Просто какая-то улица разбитых шаблонов.

Это наводит на размышления об истории и предназначении шаблонов проектирования, а также о том, когда их следует применять, а когда — нет. А что если в каких-то случаях изменение шаблона ради достижения иного или лучшего результата может оказаться правильным решением? Разумеется, мы сразу замечаем, когда какой-либо шаблон используется неправильно. Но, возможно, в некоторых ситуациях это действительно уместно? Чтобы найти ответ на этот вопрос, давайте начнем с самого начала.

Почитав недавние посты для новичков JavaScript, решил написать небольшой топик про один интересный вопрос, которого ни один из авторов пока не касался, а именно, вопрос про область видимости функций в JavaScript.

По просьбам некоторых читателей решил написать топик про контекст в javascript. Новички javascript часто не понимают значение ключевого слова this в javascript. Данный топик будет интересен не только новичкам, а также тем, кто просто хочет освежить данный аспект в памяти. Посмотрите пример ниже. Если вы затрудняетесь ответить на вопрос «что будет выведено в логе» хотя бы в одном из пунктов или хотите просто посмотреть ответы — добро пожаловать под кат.

var f = function() {
    this.x = 5;
    (function() {
        this.x = 3;
    })();
    console.log(this.x);
};

var obj = {x: 4, m: function() {
    console.log(this.x);
}};


f();
new f();
obj.m();
new obj.m();
f.call(f);
obj.m.call(f);

Разрешите представить datef — мини-JS-библиотеку вывода даты в разных форматах.
Вкратце опишу имеющиеся фичи:

• Выполняет одну и только одну задачу: вывод дат в разных, потребных юзеру форматах;
• Работает в nodejs и в браузерах. В браузерах может работать как requirejs/amd-модуль;
• Не мусорит в прототипах встроенных объектов;
• Написана в strict mode;
• Обильно аннотирована в js-doc-формате;
• Не имеет внешних зависимостей.

Примеры использования:

datef('dd.MM.YY', new Date()); // "13.08.12"
datef('dd.MM.YY'); // второй аргумент необязателен — берется «сейчас»

var d = new Date();
d.setFullYear(2045);
datef('dd.MM.YYYY', d); // "13.08.2045"

// есть несколько заранее заданных форматов:
datef.formatters.ISODateTimeTZ(); // "2012-08-13T15:01:29 -04:00"

// можно определить и сохранить свой…
datef.register('myFormat', 'd.M.YY');
datef.formatters.myFormat(); // "13.8.12"

// или просто получить его как отдельную функцию
var myFormat = datef.createFormatter('d.M.YY');

Именно о лесенках хотелось бы немного поговорить. Есть такая относительно распространенная задача с программистских собеседований:

Вы поднимаетесь по лестнице. На каждом шаге вы можете подняться либо на 1 ступеньку, либо на 2. Всего лестница имеет n ступенек. Сколькими разными способами вы можете дойти до конца лестницы?

Задача не сильно сложная, но имеющая пару интересных моментов относительно минимально возможной сложности решения и демонстрирующая «штуки, которые интересно знать».

Верстая очередной проект (или ещё только проектируя макетную сетку) многие сталкивались с дилеммой — использовать фиксированную ширину макета или «резиновую» сетку, адаптируемую под размер окна браузера.

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

Фиксированная ширина макетной сетки

Вёрстку загоняют в горизонтальный габарит 960—980 пикселей (чтобы на большинстве устройств в большинстве разрешений всё входило), что при больших горизонтальных размерах окна выглядит как-то зябко — тонкая вертикальная полоса полезного содержимого страницы и огромные бесполезные поля неиспользуемого пространства по бокам.

«Резиновая» макетная сетка по ширине окна

Опять же при больших горизонтальных размерах окна есть другая проблема: строки текста становятся очень длинными, и читать их становится совсем не так комфортно, как хотелось бы.
Ещё одна распространённая проблема этого решения — боковые отступы при больших горизонтальных размерах окна уже не так удачно визуально согласуются с горизонтальными размерами элементов, что также не добавляет комфорта при взгляде на свёрстанный макет.

Одна из сложностей, с которой, по моему опыту, сталкиваются практически все разработчики и дизайнеры, работая над приложениями для Windows 8 и Windows Phone, начинается прямо с порога – с проектирования того, как пользователь будет взаимодействовать с приложением (UX и UI).



Часто разработчик (автор приложения) приходит с некоторой готовой идей и старается напрямую перенести в Windows 8 привычную десктопную, мобильную или веб-функциональность. Обычно эта прямолинейная попытка «портирования» оборачивается стремлением сохранить все, что есть в оригинальном решении, включая схожие шаблоны решения интерфейсных задач и знакомые приемы разработки и написания кода.

Так получилось, что год назад, мне пришлось написать билд-план с использованием ant. Он предназначался для нашего небольшого веб-проекта, исполнялся на Hudson и должен был производить: компиляцию, прогон NUnit тестов, подсчет % покрытия кода тестам, поиск дублирующегося кода и выявление основных стилистических несоответствий в коде. Но это вступление, а далее поговорим, о написании билд-плана для анализа файлов проекта, посредством FxCop.

И так! Поехали!

Навеяно этим постом, где устраивающий автора ответ, судя по всему так и не нашли.

Не трогай мертвого

… пронеслась фраза у меня в голове, когда я взялся воротить этот простеиший макетик, дабы найти выход. Все-таки сейчас под старые версии IE практически никто не верстает. Часть этих ребят уверенна, что таким образом они делают неоценимый вклад в развитие веба, хотя сделать под IE6/7 проблем для них нет. Для других же просто удобно игнорировать «старый, никому не нужный браузер», ведь они никогда не умели под них верстать.

Решил все-таки написать статью про SQLite, в которой хочу обобщить свой 3-х летний опыт использования этой БД под Windows. Вижу, что тема популярная, но информации мало.

Часть 2
Часть 3

Небольшая вводная.

Эта статья не для начинающих программистов.
Она не является учебником по SQL.
Она не агитирует использовать SQLite.
Она не агитирует не использовать SQLite.
Статья написана в виде вопросов от гипотетического новичка в SQLite и ответов на них (поскольку информации очень много и так хоть немного проще ее структурировать).

Сразу спешу сообщить вам, что я никоим образом не связан с автором предыдущей статьи. Однако, прочитав ее и увидев такой положительный отклик сообщества на статью, я тоже вдохновился и решил добавить немного своих наблюдений и знаний, к тому же это может послужить моей входной точкой в круги хабрасообщества.

Для затравки начнем с простого.

Сегодня я хочу познакомить вас с замечательными примерами hover-эффектов от Mary Lou. Многим понравились её примеры с hover-эффектами для меню и на этот раз она решила порадовать нас не менее замечательными примерами для круглых элементов. Поскольку сейчас у нас есть возможность использовать свойство border-radius, мы можем создавать круглые формы, и они все чаще появляются в качестве элементов дизайна на веб-сайтах. Один из вариантов использования, который мне более всего нравится, это круглые миниатюры, которые выглядят гораздо интереснее, чем обычные, прямоугольные. И сейчас мы собираемся создать несколько необычных эффектов при наведении на такие элементы!

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

Существует определенный набор возможностей в любом языке программирования для понимания которых нужно просто знать, как они реализованы. Вот, например, замыкания; это не сверх сложная концепция, но знание того, как этот зверь устроен позволяет делать определенные выводы относительно поведения замыканий с переменными цикла. Тоже самое касается вызова виртуальных методов в конструкторе базового класса: здесь нет одного правильного решения и нужно просто знать, что именно решили разработчики языка и будет ли вызываться метод наследника (как в Java или C#), или же «полиморфное» поведение в конструкторе не работает и будет вызываться метод базового класса (как в С++).

Еще одним типом проблемы у которой нет идеального решения, является совмещение перегрузки методов (overloading) и переопределения (overriding) метода. Давайте рассмотрим следующий пример на языке C#. Предположим, у нас есть пара классов, Base и Derived, с виртуальным методом Foo(int) и невиртуальным методом Foo(object) в классе Derived:

Недостаточно писать код хорошо читаемым: он также должен быстро выполняться.

Существует три базовых правила для написания такого T-SQL кода, который будет работать хорошо. Они кумулятивные – выполнение всех этих правил окажет положительное влияние на код. Пропуск или изменение любого из них – скорее всего приведет к отрицательному влиянию на производительность вашего кода.

• Пишите, исходя из структуры хранения данных: если вы храните данные типа datetime, используйте именно datetime, а не varchar или что-нибудь еще.
• Пишите, исходя из наличия индексов: если на таблице построены индексы, и они должны там быть, пишите код так, чтобы он мог использовать все преимущества, предоставляемые этими индексами. Убедитесь, что кластерный индекс, а для каждой таблицы он может быть только один, используется наиболее эффективным образом.
• Пишите так, чтобы помочь оптимизатору запросов: оптимизатор запросов – восхитительная часть СУБД. К сожалению, вы можете сильно затруднить ему работу, написав запрос, который ему «тяжело» будет разбирать, например, содержащий вложенные представления – когда одно представление получает данные из другого, а то из третьего – и так далее. Потратьте свое время для того, чтобы понять как работает оптимизатор и писать запросы таким образом, чтобы он мог вам помочь, а не навредить.

Существует несколько типичных ошибок, которые люди допускают в своем коде на T-SQL – не совершайте их.