Хочу рассказать вам о фреймворке, который был создан для разработки «богатых» веб-приложений на ASP.NET. Фреймворк был создан в компании, в которой я работаю, и использован в нескольких боевых проектах.

Из ключевых особенностей фремворка:

• хороший JSON-форматтер (теперь на клиент можно передавать почти любые .NET-типы);
• мастерстраницы/страницы/контролы на клиенте представлены как объекты JavaScript (в JavaScript построить взаимодействие между ними теперь совсем просто);
• мастерстраницы/страницы/контролы можно наследовать, причем можно наследовать как серверный код, так и клиентский (да, даже разметку);
• можно использовать совместно с jQuery или (как делаем мы) с ExtJS;
• много всего приятного :)

Инициатор создания фремворка и его главный разработчик не я, а мой коллега. Я же просто разместил объяву хотел рассказать вам о замечательном продукте :)

Читать статью

P.S. — В топик-ссылку не поместилось описание, сделал как топик.

Этот топик является продолжением статьи о средствах проектирования.
В данной части я постараюсь рассмотреть не менее достойных представителей данной «отрасли».
Итак следующая тройка выходит на старт!

Вступление

Одним из нововведений в четвертой версии ASP.NET стала возможность контролировать формирование идентификаторов элементов разметки на клиенте. Ранее фреймворк задавал уникальный идентификатор для каждого элемента. Это приводило к тому, что определяемые вами идентификаторы преображались во что-то похожее на это: ctl00_MasterPageBody_ctl01_Textbox1.

Проблема

Модификация идентификаторов на клиентской стороне отлично работает, когда требуется обеспечить уникальность идентификаторов для каждого элемента, но работа с такими идентификаторами могла расстроить любого, кому приходилось работать с клиентскими скриптами. И если вы работали с ASP.NET, то скорее всего сталкивались с этими трудностями. Проблема состоит в том, что во время исполнения скрипта вы не можете точно знать каким может быть идентификатор, что затрудняет написание клиентских скриптов. Кроме того, любые модификации на странице, добавление или удаление элементов управления, могут привести к генерации других идентификаторов.

В этой статье я хочу по возможности полно и последовательно рассказать о том, что такое объект в JavaScript, каковы его возможности, какие взаимоотношения могут строиться между объектами и какие способы «родного» наследования из этого вытекают, как это все влияет на производительность и что вообще со всем этим делать :)

В статье НЕ будет ни слова про: эмуляцию традиционной класс-объектной парадигмы, синтаксический сахар, обертки и фреймворки.

Сложность материала будет нарастать от начала к концу статьи, так что для профи первые части могут показаться скучными и банальными, но дальше будет намного интереснее :)

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

1. Налоги
Существует основной режим налогообложения (ОСНО) и несколько спецрежимов. Один из спецрежимов — упрощенная система налогообложения (УСН, УСНО или упрощенка). Право на упрощенку имеют малые предприятия с годовым оборотом, не превышающим примерно 20 млн рублей (точную сумму можно получить, применив к сумме, указанной в главе 26.2 налогового кодекса РФ инфляционные коэффициенты). Кроме того, есть ограничение по численности штатных сотрудников (не более 100 человек) и некоторые ограничения по видам деятельности. Далее мы будем говорить только об УСНО, так как ведением учета по ОСНО не владею.

Свойство clear со значениями left, right, both действительно очищает поток в отличие от overflow со значеним hidden, которое создаёт отдельный контекст форматирования для выбранного элемента, тем самым локализуя действие свойства float внутри элемента к которому применён.

Уже неоднократно на хабре (вот в этой публикации и в этой) ставился вопрос о том, что было бы хорошо кнопкам формы, отправляемой на сервер, ставить свойство disabled = "disabled".

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

Совсем недавно группа разработчиков с ресурса Mix Online (часть Microsoft) анонсировала проект Oxite — CMS для создания блогов на базе MVC Framework. Проект находится в состоянии alpha-версии и самими разработчиками позиционируется как эксперимент, целью которого ставится показать разработчикам то, как можно писать на MVC Framework.

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

Привет, хочу представить одну интересную разработку студии, в которой я работаю. И как ведущий разработчик буду её освещать :)

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

Под производителями ПО я имею в виду те коллективы, которые а) делают ПО и продают его как собственный продукт и б) делают ПО под заказ как outsourcing-коллективы. Собственно в реализации такого каталога нет ничего сложного, кроме того, что необходимо инвестировать свой труд по сбору данных, их переводу на немецкий и реализации самого каталога. А я не ленивый.

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

В моем твиттере прошла ссылка на десять JS-фреймворков, которые интересны в плане изучения и расширения возможностей, для того, чтобы разработчики не ограничивались только верхушкой мейнстрима (имеется ввиду jQuery/Prototype/Mootools/YUI). Вполне вероятно, что что-то из этого списка завтра будет не менее популярно, да и просто для повышения своей квалификации или подсматривания интересных решений. Оригинал на английском языке здесь, а я попробую рассмотреть самое интересное со своей колокольни.

Ага, вот эти ребята, сейчас я покажу Вам магию ООП.

«Совершенный Ajax» — новый подход к построению web-приложений, при котором web-сервер не генерирует ни строчки HTML-кода и взаимодействует с внешним миром только посредством web-служб; а клиентский интерфейс реализуется только на основе клиентских HTML, CSS, JavaScript.

Статья состоит из двух частей. В первой части — более живой и провокационной я постараюсь заинтересовать проблемой, рассказать о технологии «Совершенный Ajax» и показать ее применение на примере нашего проекта «Система Интерактивного Тестирования Знаний “Синтез”» (который имеет ряд интересных особенностей, таких, как использование серверного JavaScript на платформе Mozilla Rhino, прототипно-ориентированная ORM и поддержка SPARQL — языка запросов к Semantic Web).

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

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


Попробуйте угадать: к какой архитектуре относятся web-приложения?

К клиент-серверной говорите? Я ожидал, что Вы так ответите :-)

Что ж, давайте разберемся. В клиент-серверной архитектуре выделяют:

• Сервер — отвечает за хранение данных и реализацию бизнес-логики приложения.
  
  
• Клиент — отвечает за взаимодействие с пользователем ^[1].
  
  

Реализация бизнес-логики на сервере и взаимодействие с пользователем на клиенте четко разделены.

Преимущества клиент-серверной архитектуры очевидны; мы их все знаем:

1. Бизнес-логика не смешивается с пользовательским интерфейсом.
2. Можно реализовать несколько клиентов с разными пользовательскими интерфейсами: интерфейс командной строки, оконный Windows-интерфейс, Flash, web-интерфейс, мобильный интерфейс и т.д.
3. Клиентский компьютер не требователен к ресурсам;
4. И т.д.

Но, относятся ли web-приложения к клиент-серверной архитектуре?

Действительно, в web-приложениях есть сервер, отвечающий за бизнес логику приложения.

Но! За реализацию интерфейса отвечает не клиент, а тоже сервер. На сервере происходит обработка клиентской формы. Сервер генерирует HTML-код пользовательского интерфейса.

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

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

Итак, собственно, к делу.

Мы занимаемся системами электронной биржевой торговли, аналитикой рынка и поставкой маркет-данных в реальном времени. К таким системам предъявляются повышенные требования по надежности — каждая ошибка может привести к потере больших денег.

Сложность элементов интерфейса увеличивается с каждым новым макетом, что доставляет немало хлопот верстальщикам. Развивающиеся технологии позволяют создавать в WEBе сложные приложения (Google не даст мне соврать), поэтому дизайнеры себя не сдерживают и рисуют всё более навороченные вещи. Как правило, это приводит к большому количеству графики на страницах.

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

Многие из Вас наверняка стакивались с ситуацией — есть дело важное, интересное, прибыльное (нужное подчеркнуть;), есть время этим делом заняться. А душа к нему не лежит. Стоит только сесть за работу, как как будто черт дергает послушать музыку, побродить по интернету, початиться с друзьями. Один — другой раз, не куда ни шло, но это происходит постоянно, и часто под самыми благовидными предлогами (например: дабы узнать новую информацию необходимую для проекта). Не иначе как происки нечистого.

Всем привет. В этой статье я хочу рассказать про наш небольшой стартап, кулинарный сайт livecookbook.ru, которому буквально несколько дней назад исполнился год. Не спешите листать дальше, этот топик ничем не хуже топиков о продлении жизни или о фотоконкурсах.
Мы не ставили себе целью заполучить максимальную аудиторию (поэтому вы скорее всего про нас не слышали), или заработать много денег. Нашей целью было сделать сайт, которым было бы в первую очередь приятно и удобно пользоваться самому. Мы не бросали работу, не нанимали фрилансеров. Основное рабочее время – ночь, основные помощники – наши друзья, источник большинства идей – собственная фантазия и желание иметь на ужин что-нибудь вкусное.

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

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

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

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

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

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

Итак, получили письмо от клиента

обычно есть следующие варианты

1. клиент явно перспективный и обратился «выборочно» именно к нам — есть большая вероятность, что переговоры будут удачными — тогда лучше сразу набивать стрелку и устанавливать личный контакт и все выяснять на месте. Хотя, границы бюджета лучше выяснить в любом случае.
2. клиент интересный, но многое неясно из его письма ( нет ТЗ, нет бюджета, он написал в несколько студий, сайт потенциально сложный, сайт неинтересный и тд. ). Тут важно прислать ему БРИФ на заполнение, выяснить сроки и бюджет. Согласовать бюджет сроки — уже потом встречаться в случае, если все устраивает.
3. Письмо подозрительно короткое и не «пахнет интересом». Например, «нужен обувной интернет-магазин, сколько стоит? Как быстро сделаете? Виталий» — тут вряд-ли чтото выгорит + вероятно это пробивон по ценам от конкурентов.
   В этом случае — цену говорим в полтора раза дето дороже, интересуемся «укладываемся ли мы в их бюджет» в положительном случае — можно встречаться. Иначе — скорее всего трата времени.

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

Конечно, не хотят. Никто не хочет. А некоторые хотят приносить пользу своим проектам, но не знают как это лучше делать. Или знают, но не ту книжку прочитали, поэтому от них один вред. В общем, разные заказчики бывают.

Первое, что нужно запомнить: заказчики на самом деле полезные (и не идиоты, нет).
Второе: заказчик, на самом деле, такой же ресурс, как программист или дизайнер.
Третье: основная задача менеджера проектов (мы-то с вами знаем кто на самом деле рулит вселенной (дьявольский смех)) – научиться управлять заказчиком так же эффективно, как программистами.