Язык JavaScript был представлен как язык функционального программирования. Причина заключается в том, что функции в JS не просто разделяют логику на операционные блоки, функции являются объектами первого класса, способными создавать другие объекты. Подобная зависимость от функций одновременно является как сильной стороной, так и настоящим проклятием этого языка. Сильная сторона заключается в том, что язык, обладая подобными особенностями, становится легковесным и быстрым (каким JavaScript изначально и видели его создатели). Однако если вы не знаете что делаете — однозначно ждите беды.

Я предлагаю посмотреть на паттерны вызова функций, а точнее на то, как значительно изменяется результат в зависимости от выбранного паттерна. Также мы рассмотрим как ведет себя this, в зависимости от способа вызова функции.

Итак, существует четыре пути вызова функций:

• Вызов метода — Method Invocation
• Вызов функции — Function Invocation
• Вызов конструктора — Constructor Invocation
• Вызов apply и call — Apply And Call Invocation

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



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

В то же время и исполнители, говоря о целеполагании для сайтов, часто говорят скорее о функциональности, нежели собственно о целях.

«Цели-задачи» — это что-то вроде веб-девелоперского карго-культа: большинство студий ставит макет аэропорта из соломы («Сайт должен предоставлять посетителю всю необходимую информацию и формировать солидный имидж компании») и ждёт, когда с неба свалится ящик с консервами.

Давайте попробуем разобраться, как правильно подходить к постановке задач для сайта, в этой статье из четырёх частей:

1. Поведение потребителя в «цифровую эпоху» — чем отличается сегодняшний потребитель от вчерашнего, и как это влияет на бизнес.
2. Сайт как инструмент влияния — чем отличается сегодняшний сайт от вчерашнего, и о чём нужно помнить, решив создать новый сайт.
3. Как ставить задачи для сайта? — конкретные рекомендации для заказчиков и студий. За рецептами — пролистывайте до сюда.
4. Пример блока «Назначение сайта» — демонстрация того, что должно получиться в итоге.

Ребята с webmasterworld.com решили собрать все факторы, которые учитивает Google при ранжировании сайтов. Официальным представителем было заявлено (еще на тот момент), что их более 200. Пока список выглядит так, не исключено, что некоторые пункты включают в себя несколько факторов.

Потребовалось мне вывести деньги с PayPal в России, только вот через посредников работать не хотелось.
Пришлось получить карту Payoneer для вывода PayPal на эту карту. Сколько не искал, так и не нашел полноценной, пошаговой инструкции.
Поэтому пишу сам.



ВНИМАНИЕ! Все ниженаписанное является де-юре нарушением законодательства РФ и Украины, и вообще выдумкой автора и плодом работы в фотошопе. Применяя описанное на практике, вы действуете на свой страх и риск, и ни автор, на администрация сайта не несет ответственности за ваши действия.

В оригинале название звучит как «How Not To Sort By Average Rating». Я подумал, что дословный перевод «Как не сортировать по усреднённому рейтингу» будет малопонятен и хуже отражает содержание статьи.

Постановка проблемы

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

Неправильное решение №1

Рейтинг= (Число положительных оценок) - (Число отрицательных оценок)

Привет, ребята!

Спешу поделиться хорошей новостью: мы открыли классное место, а именно коворкинг, «Рабочая Cтанция» в Парке Горького. «Рабочая Cтанция» — это далеко не первая наша вариация на тему коворкинга. И, похоже, теперь нам удалось создать то пространство, о котором мы давно мечтали.

Прочитав статью jtaby.com/2012/04/23/modern-web-development-part-1.html я узнал несколько полезных вещей, напишу-ка я их здесь дабы не забыть.

В нашей прошлой статье — «11 «рецептов приготовления» MySQL в Битрикс24» — мы, в основном, рассматривали архитектурные решения: стоит ли использовать облачные сервисы (типа Amazon RDS), какой форк MySQL выбрать и т.п.

Судя по отзывам, тема грамотной эксплуатации MySQL в больших «хайлоад» проектах — очень большая и важная. Поэтому мы решили рассказать еще о некоторых нюансах настройки и администрирования БД, с которыми сталкивались при разработке «Битрикс24» и которые используем ежедневно.

Еще раз напомню, что эта статья (как и предыдущая) не является универсальным «рецептом» идеальной настройки MySQL на все случаи жизни. :) Такого не бывает. :) Но искренне верю, что она будет полезной для вас для решения отдельных конкретных задач.

А в конце статьи — сюрприз для самых терпеливых читателей. :)

Здравствуйте, уважаемые коллеги.

Часто доводилось наблюдать (на Хабре в том числе) обсуждения безопасности веб-серфинга через публичные незащищенные WiFi сети и рекомендации по защите.

Доброго времени суток, уважаемое Харбасообщество!

Под катом изложена некоторая информация касательно написания расширений для PHP c использованием C++, почерпнутая мной из различных источников (по большей части англоязычных) и ковыряния исходников Zend Engine 2 во время разработки одного модуля для собственных нужд. Так как объем ее достаточно велик, далее я старался быть краток.

Итак, в этой части:

• Внутренний мир Zend Engine 2
• Иерархия типов данных ZE и структура модуля расширения

А вот до C++ в этой части мы так и не доберемся… =)

Маленький дисклеймер: содержимое статьи не есть истина в первой инстанции, не основывается на официальной документации (а есть ли она?) и является моим субъективным взглядом на ZE 2. Тем не менее, в свое время я был бы рад найти нечто подобное на просторах Рунета, дабы сэкономить время на начальных этапах разработки.

Привожу перевод статьи Ника Карсона. В статье собраны вместе, как мне кажется, основные правила построения интерфейса для iOS приложений.

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

2. Ориентируйтесь на устройство при создании приложений: учтите не только размер экрана, но и где и когда устройство используется. Больше всего iPad используется для развлечений между 8-11 часами вечера, перед сном, тогда как iPhone — в очереди на автобус или в кофейне. Учтите различные сценарии использования при разработке приложений – включая и то, как далеко устройство расположено от лица пользователя.

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

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

5. При адаптации приложения к экранам различных размеров, помните, что при значительном его изменении – например, от iPhone к iPad – способ использования устройства также изменится. Если размеры ограничены, используйте основные функции приложения, при их увеличении – можно включить любые дополнительные функции, которые не вошли в более сжатую версию, так как у вас появляется возможность обыграть дополнительное пространство.

За остальными 45-ю — добро пожаловать подкат.

Мы все знаем, что в мире создано несколько тысяч языков программирования. Один только список программ Hello, world с сайта Wikibooks включает в себя 230 категорий (полный список на сегодня состоит из 402 элементов). При этом известный рейтинг TIOBE подтверждает очевидное соображение: основная масса этих языков скорее мертва, чем жива. Уже на долю первого десятка языков приходится 76,77% всех учтённых TIOBE проектов. Второй десяток увеличивает эту долю до 85,61%. Стало быть, на оставшиеся 30 языков (TIOBE учитывает лишь первые 50 языков при расчёте процентов) приходится менее 15% упоминаний.

Понятно, что рейтинги заключают в себе некоторую долю лукавства, поскольку даже непопулярный по общим цифрам язык может быть крайне важен для какой-либо узкой сферы. Возьмём любимый здесь многими Erlang или Haskell (39-е и 41-е места рейтинга) или ещё более очевидные Simulink и LabVIEW, вообще не попавшие в Top 50, но незаменимые в своих областях. С другой стороны, очевидно, что языки действительно приходят и уходят, и популярность, скажем, Паскаля обречена на снижение, поскольку на смену идут более прогрессивные языки, метящие в ту же нишу. (Не будем упоминать здесь Delphi, в котором от Паскаля остался разве что базовый синтаксис. У традиционного паскалиста листинг на Delphi может вызывать такой же ступор, какой у меня вызвала первая увиденная мною программа на Visual Basic 6, с этими Private и Public, Option Strict и Dim As, напрочь отсутствовавшими в родном Бейсике ZX Spectrum.)

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

Мне повезло: я побывал по обе стороны баррикад и теперь знаю, что и как делает заказчик на проектах разного уровня и что делает фрилансер, чтобы получить или провалить такой проект. В итоге я уверен, что 95% фрилансеров говорят с заказчиком на разных языках.

Осторожно, butthurt.

Поиск сотрудников – дело нелегкое, особенно таких, которые взаимодействуют с клиентом от лица компании. Речь о менеджерах проектов. Это громадная ответственность как перед командой, так и перед клиентом. Еще более громадная ответственность на руководителе, который такого менеджера на работу приглашает.

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