В паттерне, объект создается в конструкторе, а его методы объявляются в прототипе.

Данный паттерн используется во фреймворках, таких как Google Closure Library. Нативные объекты JavaScript также используют данный паттернт.

Объявление Pseudo-class

Термит Pseudo-class выбран потому, что в JavaScript нет как таковых классов, как в других языка как C, Java, PHP и др., но данный паттерн близок к определению класса.

Автоматический подсчет ссылок (Automatic Reference Counting, ARC) для языка Objective-C был представлен компанией Apple еще в 2011 году для iOS 4.0 и выше, Mac OS X 10.6 и выше, с использованием xCode 4.2 и выше. И, хотя всё больше библиотек, фреймворков и проектов сегодня используют ARC, до сих пор среди программистов встречается либо неприятие этой технологии, либо eё неполное понимание. Опытные программисты, привыкшие к retain/release, иногда считают, что они лучше и эффективней справяться с подсчетом ссылок, чем это за них сделает компилятор, а новички, начищающие сразу использовать ARC, полагают, что им не надо вообще думать об управлении памятью, и всё сделается магическим образом само.

Для кого написана эта книга:

Книга предназначена для разработчиков, которые хотят углубить свои знания Objective-C, а также стремятся писать код, простой в сопровождении, эффективный и содержащий меньше ошибок.Даже если вы еще не являетесь разработчиком Objective-C, но у вас имеется опыт работы на других объектно-ориентированных языках (например, Java или C++), вы все равно узнаете много полезного. Впрочем, в таком случае неплохо заранее ознакомиться с синтаксисом Objective-C.

Какие темы рассматриваются в книге:

В книге не рассматриваются основы Objective-C — для этого есть много других книг и ресурсов. Вместо этого книга учит эффективно использовать язык. Она состоит из подходов, каждый из которых содержит простую и доступную информацию. Подходы сгруппированы по темам.

Однажды в студёную майскую пору обычным рабочим утром я читал Хабр. В тот день здесь появился пост от Яндекса о том, что в скором времени начнётся мероприятие по выращиванию стартапов с нуля — тогда оно было летнее и называлось Tolstoy Summer Camp. Прочитав детали мероприятия, я ещё подумал: «Два месяца? Серьёзный подход. Где-то в тридцать раз более серьёзный, чем в среднем по стартап-рынку».

Меня зовут Александр Янковский, и среди 12 готовых прототипов в финале прошлого Tolstoy Camp и трёх, которые получили инвестиции и поддержку Яндекса, был и мой проект Speaking Mind — агрегатор новостей, который умеет их зачитывать. Сегодня я хочу рассказать о своём личном опыте на Tolstoy Camp, что мне дали эти два месяца, и почему это стоит внимания.

Сразу признаюсь, что поводом для этого поста стало то, что сегодня Яндекс объявляет о наборе в новый Tolstoy Startup Camp — мастерскую для тех, кто хочет научиться создавать, разрабатывать и запускать стартапы. Как и в прошлом году, Яндекс ждёт заявки от разработчиков, дизайнеров и менеджеров. Никаких требований к образованию, опыту или месту, где вы живёте, нет, а иногородним оплачивает проживание в Москве. В этот раз занятия будут проходить весной — с 3 марта по 25 апреля. Если готовы участвовать, заполняйте анкету и приступайте к тестовому заданию.



Итак, постараюсь рассказать о том, как я стал участником кэмпа и что он мне дал.

Disclaimer. Монолог ниже является стенограммой выступления одного из докладчиков на одной из айтишных конференций. Автор поста всего лишь публикует его здесь с разрешения докладчика.

Всем привет!

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

Меня зовут Сергей. Чтобы сказать про себя «я плохой докладчик», нужно хотя бы им, докладчиком, быть. Я вообще не оно. Свою первую и одну из последних презентаций я провел в 18 лет в Испании, перед аудиторией человек в 100. Мой весьма средний на тот момент английский синхронно переводили на испанский, народ зевал и почесывал репы, ожидая когда ЭТО недоразумение закончит блеять и объявится кофебрейк.

Сказать что мне было стыдно — это ничего не сказать, красный как рак, я свалил вторым выходом, забился в свой номер и боялся показаться на глаза. Всякие public professionals типа Карнеги сказали бы «позор!» и «never again!». Для себя я решил — все что угодно, хоть жигулевское пиво по пятницам, только не публичные экзекуции

К чему это я? Многие, глядя на ИТшников, путают скромность со стеснительностью. Да и фиг с ними. Главное — чтобы мы сами не путали. Я — стеснительный, поэтому буду смотреть в пол и читать по бумажке. Я бы выпил, конечно, для смелости, граммчиков сто (а лучше сто пятьдесят), но организаторы запретили. Ну что, пусть фигово, зато честно!

Я владелец компании П, в которой мы уже лет 13 или 14 занимаемся разработкой всякой фигни, про которую никто не слышал. Не имея таланта делать что-то красивое и эстетичное, мы довольствуемся подводной частью айсберга: софт-свитчи и клиенты для IP-телефонии, аппаратно-программные решения для высоконагруженных систем обработки контента, системы имперсонализации web и e-mail для виртуального присутствия, облачное видеонаблюдение, несколько справочных и торговых интернет-порталов, ну и еще пара проектов в стадии стартапа, говорить о которых рано, потому что стыдно

Все о чем собираюсь сказать, основано исключительно на личном опыте, относится к маленьким компаниям и совершенно не обязано работать в больших, хотя иногда бывает. За 25 лет, отданных айти-бизнесу, я умудрился побывать в разных шкурах, от техника, подносящего кофе джуниор девелоперам, до владельца компаний, которому не надо вставать в 8. Посредине между этими сомнительными гранями было, наверное, два главных увлечения — язык Си и темное ирландское пиво. Увы, и то и другое со временем пришлось сильно урезать.

Друзья! Мы все очень любим (или не любим) поговорить о шаблонах проектирования. Лично я их сильно недолюбливаю, т.к. большинство из них достаточно очевидны для более или менее опытного разработчика, а шаблонность мышления еще никому в жизни не помогала.

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

В повседневной жизни я стараюсь не употреблять слово «программист». Оно для меня несет негативный оттенок и сразу вспоминаются 90-е, когда кого только программистами не называли. Они и картриджи у принтеров меняли и бабушкам-бухгалтерам помогали их первый комп осваивать. Помните это нетленное «Ты же программист!»? В общем дискредитировало себя это слово.

Я как-то привык своих людей называть разработчиками (developers) и для меня программист — это эдакий антипод разработчика. Ну и с годами опыта я познал большое количество антипаттернов для хорошего разработчика, пользоваться которыми он должен как можно реже. Чем реже я их слышу, тем я счастливее. Итак, приступаем.

001. А у меня на компе работает

Эта фраза знакома всем, кто хотя бы несколько месяцев работает в индустрии и просто должна быть исключена из лексикона любого разработчика. Чувак, если ты отправляешь на тестирование код, который не работает у тебя на компе, то тебе не место в профессии! По определению у тебя на компе код всегда работает. Разве может быть иначе? А не работает он у тестировщика, клиента, да кого угодно, потому, что ты не учел какие-то нюансы, различия в окружении, данных, погоде на Марсе и твоя задача выяснить, что именно и исправить, а не пытаться сразу откосить и доказать свою невиновность. Нет ничего страшного в том, что ты чего-то не учел. В моей практике бывали случаи учесть которые мог бы только… Да никто не мог бы!

Итак, в мае 2013 года на хабре появилась статья «Сколько стоит сделать браузерную игру», где господин viacheslavnu пробовал посчитать — какая сумма средств потребуется на создание и продвижение, казалось бы, простецкой игры для офисного потребителя. Если кто не помнит – сумма получилась в районе 25 миллионов рублей. На тот момент я сам несколько скептически отнесся к указанной сумме, но чем ближе подходила дата нашего старта, тем больше я убеждался, что даже для таких проектов нужны «особенные» вложения капитала, которые не всегда по карману разработчикам без инвестора со стороны.

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

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

Это пост для тех, кто начинает работу с Git. Все, что здесь написано по частям можно найти в многочисленных простынях о Git на Хабре. Но я подумал, что неплохо было бы иметь отдельный предельно понятный топик, который бы гуглился по запросу «git изменение коммитов».

Доброго времени суток и с прошедшим Днем народного единства! Хочу рассказать об одном хорошем проекте — .


OAuth.io — это API (JavaScript, PhoneGap, iOS, Android, Flex) и сервис, который значительно упрощает взаимодействие более чем с 80-ю oAuth провайдерами (Facebook, Twitter, VK, GitHub, Dropbox, и др). Сервис работает по модели freemium: до 5000 соединений в месяц сервис бесплатный, при большем количестве вас ждут вполне демократичные цены. Стоит также сказать, что проект полностью открытый и вы сможете сами запустить у себя серверную часть «OAuth IO Daemon» (GitHub).

Появление кружка

Предыстория этого кружка началась два года назад. К тому времени я уже несколько лет подрабатывал репетитором информатики и программирования, в основном ученики по информатике программировали на Pascal, он больше распространен в школах.
А осенью 2011 года у меня появился необычный ученик: ребенок в 4 классе очень хотел заниматься программированием, и узнав что я обучаю Delphi мы с его мамой договорились что попробуем обучить на нём. Ребенок оказался очень одарённым, и у нас получилось очень хорошие и плодотворные занятия. И многие идеи появились только благодаря его постоянному интересу к программированию.

К тому времени я работал в кружке робототехники Дворца Молодёжи Свердловской области. И у меня появилась мысль организовать такой кружок программирования у нас. Для создания этого кружка прежде всего надо было определить несколько вещей:

• на какой возраст рассчитываем. Дело в том что я много изучал психологию (закончил психфак УрГПУ), и знаю что логическое мышление начинает развиваться (и наиболее хорошо развивается) начиная с младшего подросткового возраста. И занятия программированием будут в плане развития наиболее ценны для подростков. Это прежде всего это развитие способности держать в голове большие объёмы информации, и выстроенные между ними логические связи. Итак возраст был определён минимум от 11 лет и старше (рекомендуемый возраст 13-15 лет);
• цели обучения программированию (особенно учитывая возраст детей). Первая цель как написано выше — развивающая. Вторая цель — заинтересовать, приобщить детей к этому занятию. Именно поэтому (да простят меня сторонники традиционного обучения, требующие сначала обучать на обычном языке, а потом уже на объектно-ориентированном) было четкое понимание, что именно программы с графическим интерфейсом будут интересны детям. Итак мы переходим к третьему аспекту:
• в какой среде программируем. В качестве такой среды был выбран Lazarus. Во-первых синтаксис Pascal куда проще для детей, поэтому я решил отказаться от того же С#. От Delphi пришлось отказаться, потому что учреждение областного уровня не может позволить поставить пиратский софт, а на покупку софта для нового кружка скорее всего денег бы не нашлось. Поэтому был выбран бесплатный Lazarus

Довольно часто во многих статьях я вижу, как люди захватывают контекст this для использования в анонимной функции и удивляюсь — то, что уже стало стандартом — просто ужасная практика, которая противоречит всем канонам программирования. Вам знакома такая запись?
var self = this;
Может вам тоже стоит переосмыслить этот аспект?

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

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

ffmpeg — это кроссплатформенная open-source библиотека для обработки видео- и аудиофайлов. Я собрал 19 полезных и удивительных команд, покрывающих почти все нужды: конвертация видео, извлечение звуковой дорожки, конвертирование для iPod или PSP, и многое другое.

1. Получение информации о видеофайле

ffmpeg -i video.avi

2. Превратить набор картинок в видео

ffmpeg -f image2 -i image%d.jpg video.mpg

Эта команда преобразует все картинки из текущей директории (названные image1.jpg, image2.jpg и т.д.) в видеофайл video.mpg

(примечание переводчика: мне больше нравится такой формат:

ffmpeg -r 12 -y -i "image_%010d.png" output.mpg

здесь задаётся frame rate (12) для видео, формат «image_%010d.png» означает, что картинки будут искаться в виде image_0000000001.png, image_0000000002.png и тд, то есть, в формате printf)

В январе месяце этого года мы анонсировани книгу Сергея Тарасова "Дефрагментация мозга. Софтостроение изнутри" (http://habrahabr.ru/company/piter/blog/165327).
Прошло положенное время и книга вышла в свет.

На момент написания этой статьи в JavaScript еще не существовало официальной модульной системы и все эмулировали модули как могли.

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

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

Дело в том, что раньше не думали, что на JavaScript можно делать огромные проекты, а не просто «пропатчить DOM», поэтому о модулях не думали. Да и вообще не думали о будущем. И тут Внезапно будущее нагрянуло! Все вроде-бы уже есть, а модули в JavaScript, мягко говоря, запаздывают. Поэтому разработчикам приходится крутиться и выдумывать какие-то эмуляторы модульности.

Думаю многие из вас читали прекрасную статью Addy Osmani Writing Modular JavaScript With AMD, CommonJS & ES Harmony, которая стала одной из глав его книги Learning JavaScript Design Patterns в этой статье рассказывается про «современные» JavaScript модули или же читали достаточно старую статью JavaScript Module Pattern: In-Depth 2010 года про «старые» модули.

Я не буду переводить эти статьи и не буду делать из них солянку. В своей статья я хочу рассказать о моем модульном пути. О том как я проделал путь от «старых» модулей к «новым» и что использую сейчас и почему.

Здравствуйте, Хабралюди.

Мал по-малу из моего опыта и наших проектов родилась небольшая библиотека для работы с моделями в джаваскрипте. Она так и называется — Model.js.

Я расскажу вам вкратце об этой библиотеке и этим постом запрашиваю обратную связь у тех, кто создавая сложные джаваскрипт-приложения, уже решает эту проблему каким-то определенным образом без фреймворков. Интересно также и мнение тех, кто только подыскивает подходящий инструмент для своих нужд: какой инструмент вам нужен и насколько вам подходит Model.js?

Computer programs are the most complex things that humans make. It is also the nature of software to be extensively modified over its productive life. If we can read and understand it, then we can hope to modify and improve it.

Douglas Crockford, автор спецификации JSON

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

Есть много способов превращения JSON в Objective-C обьекты, однако многие из них имеют свои недостатки, которые мешают с ними работать. Есть известный и любимый многими RestKit, однако он, к сожалению, эффективно работает только при наличии идеального REST API. Шаг в сторону — и вы будете забивать гвозди микроскопом, не понимая, зачем нужно писать такие сложные конструкции для достаточно простых вещей. Есть решение от разработчиков GitHub — Mantle, однако с ним вы будете вынуждены наследоваться от базового класса Mantle и постоянно использовать NSValueTransformer — не самую популярную технологию в iOS/Mac OS разработке.

Я хочу рассказать о фреймворке, который недавно нашелся на просторах GitHub, и который позволяет достаточно просто и красиво преобразовывать JSON в Objective-C обьекты — EasyMapping.

Если заинтересовались, добро пожаловать под кат!

Вступление

Я безумно люблю различные эксперименты на JS. Они словно позволяют заглянуть нам в будущее, и посмотреть, каким захватывающим и футуристичным оно будет. Когда вы будете просматривать приведенную подборку, вы наверняка вспомните про еще недавнего короля — Adobe Flash, а затем осознаете, насколько быстро CSS и JavaScript лишили его трона. Современные браузеры позволяют нам использовать множество различных эффектов и анимаций без сильных тормозов. Однако слово «экспериментальный» подразумевает ряд ограничений, как например некорректное отображение в некоторых браузерах (IE), кроме того, подобные плагины будут, скорее, отличным концептуальным дополнением для персональных страниц, а не для использования в больших проектах.

Meny

Meny — трехмерное меню, которое помимо своей визуальной притягательности еще и экономит место на экране. При наведении (или свайпе на тачскрине, что важно), меню «выезжает» с отличным эффектом.

Fluid UI: очень удобное HTML5-приложение для создания прототипов мобильных интерфейсов в браузере (Chrome или Safari). Буквально за пару минут можно сделать приличный набросок.



Поддерживает жесты, действия на прикосновения, драг-н-дроп, переходы между страницами, дублирование шаблона на несколько страниц, библиотеки iPhone и Android, загрузку пользовательских изображений и скриншотов. Ссылку на созданный дизайн можно быстро отправить коллеге или протестировать на мобильном устройстве. Можно экспортировать в PDF, HTML или графический формат.