С появлением HTML5 у нас появляется много новых и интересных возможностей. Позволяющих создавать еще более качественный приложения.
Например, File API. Доступ к файлам клиента довольно удобная штука. Мы можем к примеру заполнить форму используя информацией из выбранного пользователем файла:
Здравствуйте, читатели-маководы!
Сегодня мы с вами попробуем разобраться в азах создания виджета для Dashboard в Mac OS X. Нам понадобится программа Dashcode, предназначенная как раз для этого.
Для начала немного теории. Виджет в Dashboard — это специально сформировання веб-страничка, упакованная в бандл вместе со всем ресурсами. Ну, и немного служебной информации в довесок. Соответственно, используемый язык программирования — JavaScript. Если Вы уже знакомы с ним, а так же с HTML/CSS (хотя это вряд ли понадобится), то Вы уже способны написать простенький виджет. Если же нет, то не стоит расстраиваться, этот язык очень прост и интуитивно понятен, разобраться с ним можно достаточно быстро. Далее я буду считать, что с JS читатель более-менее знаком. Сама же статья рассчитана на новичков, так что прошу не ругать за «слишком простое изложение и детальное разжёвывание элементарных вещей». Кроме того, за дизайн тоже прошу не пинать — ну не дизайнер я, не дизайнер! Если кто хочет помочь с этим делом — welcome =)
Для удобства, все исходники (а так же готовый к использованию виджет) выложены на гитхаб, ссылка в конце статьи. Но не спешите просто скачивать их! Лучше потратить немного времени и разобраться, как создать это всё самому.
Итак, приступим. В качестве цели для экспериментов я, разумеется, выбрал наш любимый хабр. Мы будем шаг за шагом делать виджет, отображающий карму, рейтинг и позицию в рейтинге хабралюдей выбранного читателя.
Такой виджет (ну, очень похожий) уже был создан хабратоварищем neoromantic аж в 2007 году, но ссылки на скачивание не рабочие, а кроме того, та статья не содержала практического руководства по созданию подобных виджетов.
Читать полностью »
Разработка кроссбраузерного юзерскрипта HabrAjax подошла к той стадии, что для установки его в Опере требуется отдельная обширная инструкция, шире обычной. Причина — в том, что используется работа с другим доменами, один из которых — на протоколе HTTPS (plusone.google.com — кнопки Google Plus), и проверяются обновления скрипта на другом домене — userscripts.org. Всё это требует дополнительных настроек, которые в своё время были описаны прямо в юзерскрипте (ссылка в настройках "примеч.для Оперы"), но сделаны довольно кратко и с одной иллюстацией. Здесь посмотрим на вопрос шире, чтобы пользователи Оперы и разработчики юзерскриптов для неё имели инструкции под рукой и полностью понимали широту вопроса. Заодно, описаны места установки юзерстилей. Для тех, кто всё это знает, полезно будет посмотреть абзац выводов с 2 замечаниями в самом низу.
Читать полностью »
Классный jQuery плагинчик может применить blur на любой html элемент.
Работает в canvas используя алгоритм StackBlur.
Добрый день. Наверняка многие видели приложение для iOS под названием Flipboard. При всех его достоинствах, лично меня оно в первую очередь порадовало своими забавными анимациями перелистывания. Родилась идея реализовать нечто подобное для своего сайта исключительно на Javascript и CSS3.
В данном случае я использовал CSS3 свойство transform: rotate3d(...), которое требует поддержки аппаратного ускорения графики и адекватно работает только в Chrome 16+, поэтому все нужyые свойства я ограничил префиксами -webkit-. В продакшене для пользователей с неподходящим параметрами я заменял анимацию на более простую.
Вот так выглядит готовый результат:
Добрый день.
В заключительной части про написание собственного генератора LALR-парсеров я бы хотел описать возможные особенности и фичи. Кроме того я опишу чего мне не хватало в существующих решениях и ради чего я начал писать свой велосипед.
Дабы задать контекст, сообщу, что грамматика для анализа — это ECMAScript, так же известный как JavaScript. Конкретная спецификация — ECMA-262, редакция 5.1 от июня 2011 года.
Читать полностью »
Здравый смысл веборазработчика подсказывает, что во браузерном джаваскрипте глобальные переменные являются свойствами объекта window — так что window.чегоНибудь и просто чегоНибудь должны быть синонимами и вести себя одинаково (если, конечно, мы не находимся в какой-нибудь такой функции, где переменную чегоНибудь переопределили локально).
Здравый смысл веборазработчика также ещё подсказывает, что неопределённая переменная должна иметь значение undefined — так что чегоНибудь и undefined должны быть синонимами и вести себя одинаково, если переменную чегоНибудь не упоминали в джаваскрипте, и если какой-нибудь чудила не дерзнул переопределить undefined.
Но если вы собираетесь программировать для Opera 11 (будь то начальная версия Opera 11.01 или новёхонькая Opera 11.61), то будьте готовы отречься от здравого смысла в обоих сих случаях! (Да и не только в Opera, как я покажу чуть ниже.)
Чтобы нагляднейше убедиться в этом, воспользуемся библиотекою Underscore.js, в которой как раз имеется удобная функция тестирования неопределённых переменных — это функция _.isUndefined(), в исходном коде определённая самоочевидным способом:
// Is a given variable undefined?
_.isUndefined = function(obj) {
return obj === void 0;
};
.jpg "Хождение по мукам: верстка для Safari под iOS (ч.1)")
Доброго дня!
Работая в успешной веб-студии, ориентированной на западный рынок, практически не существует проекта, в ТЗ к которому нет строки «корректное отображение на мобильных устройствах». Под мобильными устройствами в данном случае подразумеваются смартфоны и планшеты под управлением Android и iOS. Таким образом, современному веб-разработчику (дизайнеру / программисту / верстальщику) никак нельзя не учитывать особенности отображения конечного продукта на вышеупомянутых девайсах.
Нельзя сказать, что валидный, кроссбраузерный код, который корректно отображается на старших настольных братьях даст совершенно иную картину при запуске на мобильной платформе — сейчас уже ситуация обстоит куда лучше, нежели раньше. Однако, как показывает практика, все еще остались некоторые нюансы, которые необходимо учитывать. О тех, с которыми мне пришлось столкнуться в процессе тестирования в Safari под iOS я хочу сегодня рассказать.
Я был вдохновлен 2мя статьями, этой и этой. Мне очень понравилась идея первой статьи, но я подумал, что покупать Arduino для этой затеи было бы слишком «жирно». Затем, когда я наткнулся на вторую статью, я понял, что Yoctopuce-demo -как раз то, что мне надо! И я решил заказать его.
Читать полностью »
Проблемы интеграции своих программ с чужими все более широко охватывают область разработки программного обеспечения. Многие программисты считают, что нужно писать свое, интегрироваться с чужими разработками это плохо, причем не учитывают размеры команд разработчиков, их опыт и целесообразность. Да и в течении года-два реализовать ту же самую систему расчета методом конечных элементов хоть и можно, но высокого качества она не будет. Разве можно за пару лет повторить путь развития проекта, который развивался 10–20 лет? Естественно нельзя и часто нецелесообразно.
Никто ведь не спорит, что в России самыми популярными программными средствами являются ANSYS, ABAQUS, SCAD, LIRA, PLAXIS и т.д. И какова вероятность занять свою нишу в этом уже давно поделенном участке рынка? Да и мало кто захочет переучиваться под новую программу. А вот проблемы интеграции своих программ с мощными расчетными системами и перенос результатов из одной в другую задача намного более востребованная. Мы имеем мощные вычислительные пакеты, на разработку и отладку которых ушло много лет, имеем некую задачу, реализовать которую в одной вычислительной системе подчас весьма сложно, или отсутствуют необходимые нам возможности, которые мы можем сами реализовать.
Этой задачей я занялся при необходимости выполнить параметрическую оптимизацию моделей материалов, для соответствия результатов моделирования группы реальных испытаний с их расчетными моделями. Это еще усугубляется тем, что каждый программный продукт считает по своему и результаты расчетов в ANSYS не будут идентичными расчету в ABAQUS при одинаковых параметрах модели. Это зависит от конкретной реализации расчетов, типов конечных элементов и даже расположения узлов сетки. В итоге инженер вводит параметры материалов, не зная, на сколько точно они соответствуют реальности. Причем вариативность оптимальных параметров может достигать 70% от результатов испытаний, тем более что обработка испытаний выполняется в рамках одной, максимум двух условий прочности, зачастую самых простых, а для сложных моделей не всегда даже известно как определить требуемые параметры, особенно когда их предлагают задать исходя из опыта в каком либо диапазоне.
Именно для решения этой проблемы и была поставлена задача интегрировать программу с расчетным ядром ANSYS. Задача интеграции была успешно решена, хотя и не без проблем. Причем главной проблемой оказалось полное отсутствие документации в свободном доступе, так что я думаю информация по реализации интеграции будет весьма полезна тем, у кого возникли такие же проблемы, как и у меня.