Программирование для начинающих

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

В отличии от стандартных компонентов, основанных на QTWidgets, Kirigami UI является надстройкой над Qt Quick Controls за счет чего появилась возможность поддержки тулкитом сенсорных экранов.

По своей сути Kirigami UI просто доплняет Qt Quick  более высокоуровневыми элементами, реализующими собственный подход к дизайну и построению интерфейса.

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

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

В конце апреля ожидается первый выпуск фреймворка, который будет сформирован в виде обособленного продукта. В дальнейшем компоненты Kirigami планируют включить в состав набора KDE Frameworks 5, в котором Kirigami получит статус фреймворка первого уровня, т.е. не будет связан зависимостями с какими-либо компонентами, кроме Qt. Первой программной на базе нового фреймворка стало ПО для дайверов Subsurface-mobile, изначально основанное Линусом Торвальдсом. В настоящее время сформирован выпуск Subsurface-mobile для Android и готовится версия для iOS, основанная на той же кодовой базе.

Сегодня был представлен релиз SQLite 3.12.0  (встраиваемая реляционной СУБД)

Потенциально разрушительное изменение:

• Значение SQLITE_DEFAULT_PAGE_SIZE увеличено с 1024 до 4096. 
• Значение SQLITE_DEFAULT_CACHE_SIZE изменено с 2000 на -2000, таким образом такое же количество кэш-памяти используется по умолчанию. 

Основные изменения:

31 марта 2016 года случилось событие, которое мы не могли обойти стороной. На конференции Build компания Microsoft расскажет о последних нововведениях Windows 10 Redstone. Перед самым началом стало известно, что на конференцию приглашены сотрудники Canonical (разработчики Ubuntu Linux).

Как оказалось, Microsoft совместно с Canonical  проводят проект интеграции операционной системы Ubuntu внутрь Windows 10, что дает возможность использования нативных приложений для GNU/Linux совместимых с Ubuntu Linux без перекомпиляции под платформу Windows 10.

В своём блоге один из сотрудников Ubuntu Product and Strategy (Дастин Кирклэнд) опубликова некоторые факты и подробности.

Из его блога: «Это немного странно для меня потому, что я не использовал Windows уже около 16 лет. Но всё изменилось пару месяцев назад, когда погрузился в сверхсекретный (и абсолютно невероятный) проект между Microsoft и Canonical, который анонсировал сегодня во вступительной речи Кевин Галло».

В новом билде Windows 10 пространство пользователя Ubuntu и оболочка bash работают нативно в консоли cmd.exe! В доказательство - скриншот:

1. Пользователь Windows 10 открывает меню «Пуск»
2. Набирает там "bash" и нажимает клавишу "Еnter"
3. Открывется консоль cmd.exе с запущенным /bin/bash от Ubuntu, с полным доступом ко всему пространству пользователя Ubuntu и стандартных "гнутых" утилит, таких как apt, ssh, rsync, find, grep, awk, sed, sort, xargs, md5sum, gpg, curl, wget, apache, mysql, python, perl, ruby, php, gcc, tar, vim, emacs, diff, patch...и большинство из десятков тысяч бинарных пакетов в архивах Ubuntu!

Дастин Кирклэнд говорит, что это не виртуальная машина, никаких контейнеров и не Cygwin, а нечто похожее на эмулятор, где системные вызовы Linux в реальном времени транслируются в системные вызовы Windows. Сейчас в Windows 10 используется Ubuntu 14.04 LTS.

Microsoft называет это "Windows Subsystem for Linux" (исходный код пока закрыт). Трансляция вызовов очень эффективная: утилита sysbench показывает почти одинаковую производительность CPU, памяти и операций ввода/вывода.

Интересно и логично выглядит работа с логичискими дисками. Все логические диски, вроде C:, монтируются для чтения и записи в директории "/mnt". Т.е., на пример: "/mnt/c", "/mnt/d" и т.д. И наоборот, файловая система Ubuntu доступна через «Проводник» в "C:\Users\Kirkland\AppData\Local\Lxss\rootfs\".
Большинство утилит уже работают нормально (например, с ssh нет проблем и его работу продемонстрировали перед публикой), но есть ПО, которое пока не очень хорошо работает: byobu, screen и tmux. Но всё равно Microsoft и Canonical проделали огромную работу, что такое вообще стало возможным.

Данная статья посвящена быстрому введению в азы языка tcl, который для меня стал первым промышленным языком, изученным самостоятельно по той же схеме (в виде уроков на сайте), которую будут использовать наши читатели. Прежде чем переходить к самому уроку - давайте разберемся, что же это за язык такой.
Язык Tcl
Tcl (от англ. Tool Command Language — «командный язык инструментов», читается «тикль» или «ти-си-эль») — скриптовый язык высокого уровня.
Tcl часто применяется совместно с графической библиотекой Tk (Tool Kit). Связку Tcl/Tk по-русски иногда называют «Так-тикль» (английский вариант — «тикль-ток»).
Области применения языка — быстрое прототипирование, создание графических интерфейсов для консольных программ (пакетов программ), встраивание в прикладные программы, тестирование. Также Tcl применяется в веб-разработке.

Немного историиЯзык разработан Джоном Оустерхаутом (John Ousterhout) в то время, когда он работал в университете Калифорнии в Беркли. Первоначальной целью было создание универсального языка для встраивания в консольные приложения. Вслед за этим Оустерхаут расширил свой язык средствами создания графических интерфейсов — так появился Tcl/Tk.
За 4 года развития в университетских стенах Тикль-сообщество выросло до нескольких сотен тысяч программистов. В 1993 году было разработано первое объектно-ориентированное расширение — incr Tcl.
В 1994 г. Оустерхаут становится ведущим инженером проекта SunScript. В течение следующих 4 лет, став одним из проектов корпорации Sun, Тикль не только остался свободно распространяемой системой, но и значительно усовершенствовался, стал кросс-платформенным.
Заметный удар по популярности языка нанёс Ричард Столлман, опубликовав в сентябре 1994 г. в ряде новостных групп рекомендацию «Почему вы не должны использовать Tcl». В ней он на основании утверждений, что «Tcl разработан не как серьёзный язык программирования» и «Tcl имеет особый синтаксис, притягательный для хакеров из-за своей простоты. Но синтаксис Tcl кажется странным для большинства пользователей.», а также в связи с продвижением Emacs Lisp вынес вердикт: «проект GNU не собирается использовать Tcl в программном обеспечении GNU». Помимо субъективных претензий к дизайну языка, Столлман указал на объективный на тот момент недостаток — низкое быстродействие.
Тем не менее, рост количества разработчиков, активно использующих тикль, составил за этот период 600 %.
В 1998 г. в связи с Java-бумом и связанной с ним острой конкурентной борьбой корпорация уже не могла уделять тиклю прежнего внимания. Джон Оустерхаут покидает Sun и создаёт (при поддержке Sun) компанию Scriptics, продолжая развитие технологии Tcl/Tk. Это была одна из первых коммерческих программных фирм, чья деятельность строилась вокруг бесплатного свободного ПО.
Цветовое решение логотипа, принятое в 90-х гг. XX века
В марте 1998 года Оустерхаут пишет ставшую классической статью «Сценарии: высокоуровневое программирование для XXI века», в которой назвал скриптовые языки языками системной интеграции, потому что они ориентированы прежде всего на работу с объектами операционной среды, а не с элементарными данными. Это позволяет без написания тысяч строк кода двумя-тремя командами «склеивать» такие объекты в одно целое.
В том же году он выиграл за разработку языка Tcl две крупных награды. Первая — это ACM Software System Award, вручаемая за «наиболее значимое программное обеспечение». Этой наградой до этого были отмечены такие основополагающие системы, как стек протоколов TCP/IP, первая электронная таблица, первая реляционная база данных, World Wide Web, Unix, PostScript и Smalltalk. Вторая — это ежегодная USENIX Software Tools User Group (STUG) Award, в знак признания выдающегося программного обеспечения.
В 1999 году выходит Tcl 8.0 — в этой реализация впервые появилась компиляция в байткод, что позволило в 6 раз поднять быстродействие. В следующую модификацию Tcl 8.1 введена полноценная поддержка юникода, в ней впервые реализована многопоточность. В связи c этим релизом Оустерхаут заявил: «В целом 8.1 переводит Tcl в новую категорию, поскольку теперь его можно использовать для серверных приложений. Си, Си++ и Java можно по-прежнему использовать для создания частей приложений, критических с точки зрения производительности, а Tcl — для интеграции и создания интерфейсных компонентов».
В 2000 году фирма Scriptics была переименована в Ajuba Solutions, а затем куплена фирмой Interwoven, не заинтересованной в работе со свободным ПО. В связи с этим разработка Tcl была передана сообществу программистов. Так была сформирована Tcl Core Team.
На 9-й конференции по Tcl/Tk, проходившей в Ванкувере, была представлена виртуальная файловая система StarKit, обеспечившая новый, удобный для обычного пользователя способ распространения Tcl программ.
(Данный материал взят со всеми любимой Wikipedia: https://ru.wikipedia.org/wiki/Tcl)

А теперь немного моего личного мнения. Как таковой язык Tcl является прекрасным языком программирования, который имеет массу библиотек (его количество "батареек" сегодня одно из самых больших), выдержан временем (т.е. в нем уже нет детских болезней, как у того же Go), а так же - он по настоящему прост в изучении. Освоить его можно за пару дней! И при этом язык будет полезен как системному администратору (скрипты пишутся очень удобно), так и программисту.

TCL: причины низкой популярностиДля начала огорчу тех, кто с пеной у рта кричит о том, что "Tcl не нужен" или "Tcl - мертв". Для опровержения последнего - посмотрите на дату выпуска последней версии интерпретатора Tcl/Tk.
Про первое - не нужный язык не станут использовать AOL, BMW, CPU за его создание не станут давать ACM Software System Award. В настоящий момент разработки на Tcl/Tk ведутся в основном в недрах компаний, которые пишут на данном языке программное обеспечение для внутреннего пользования.  Поэтому говоря о непопулярности Tcl/Tk мы прежде всего говорим о его непопулярности среди разработчиков настольных пользовательских приложений.
Следующие аргумент, который выдвигают в качестве непопулярности Tcl/Tk - это то, что стандартный вид набора виджетов не красивый, как пример - приводят jabber-клиент tkabber. По данному заявлению стоит отметить - набор стандартных виджетов имеет по умолчанию значения атрибутов, которые соответствуют бородатому Motiff, внешней вид которого действительно является немного анохроническим.
Но зачем использовать значения по умолчанию? Опытный разработчик на Tcl/Tk способен сделать интерфейс по внешнему виду ничем не уступающий большинству приложений.
Далее - сегодня Тк поддерживает "темы" и внешне может подстраиваться под внешний вид графического окружения операционной системы, что делает программы на Tcl/Tk неотличимымы от их аналогов чисто внешне.
Существенным минусом для многих команд разработчиков коммерческого ПО стало то, что программы на языке до сих пор распространяются в виде исходных кодов, без предварительного перевода в байт-код, т.е. программное обеспечение написанное на Tcl/Tk является ПО с открытым исходным кодом. А большинство разработчиков коммерческого ПО избегают этого.
Среди разработчиков свободного ПО с открытым кодом популярность Tcl стала меньше благодаря FSF и Ричарду Столлману в частности. В сентябре 1994 году RMS надолго "утопил" продуктивные идеи Tcl/Tk своей рекомендацией "Почему вы не должны использовать Tcl" в котором концентрируется внимание на якобы невозможно сложном синтаксисе Tcl (приводя в качестве контраргумента язык с куда более тяжелым синтаксисом, но четкой семантикой, - Lisp) и о "подкупающей хакеров простоте Tcl". Не разобравшись с основными идеями "раширяемости" и "расширения" Тикл, RMS наносит последний удар, утверждая, что Tcl пригоден только для маленьких приложений и выносит вердикт: "Поэтому проект GNU не собирается использовать Tcl в программном обеспечении GNU". Особенно странно это ввиду того, что Lisp и Tcl имеют общие черты и идеи, в частности - та же расширяемость. Несмотря на все старания Столлмана Tcl так и не "потонул", а "лисп" не смог занять ведущую позицию среди языков для разработки настольных приложений.
Как видит пытливый ум - нет не одной объективной причины не изучать и не использовать Tcl. Перед тем как перейти к уроку, давайте еще пройдемся по самым часто задаваемым вопросам по этому языку.

Часто задаваемые вопросыВопрос (В): Что такое Tcl?
Ответ (О): Tcl - это скриптовый язык программирования высокого уровня. Считается одним из трех классических скриптовых языков. До пришествия РНР использовался вместо последнего. Очень тесно взаимосвязан с тулкитом Tk, что позволяет в короткие сроки писать достаточно функциональные программы с GUI.
В: Зачем учить Tcl, ведь можно использовать любой скриптовый язык с привязкой к Tk?
О: Можно. Но лучше использовать любой тулкит в "родной" для него среде (код выглядит органичнее). Да и программы на чистом Tcl/Tk работают быстрее, чем при помощи мостов для Ruby/Tk, Perl/Tk и пр., так как тащат за собой обе среды исполнения. Так же страдает от этого переносимость программ и скриптов - для запуска файла будет требоваться установленную среду не только скриптового языка, на котором написана программа, но и Tcl/Tk (первый необходим как раз таки в качестве "моста").
В: Но есть же Lisp!
О: Да, он есть. И Tcl с ним некоторые программисты сравнивают. Даже называют "Tcl - Lisp On Drugs". Языки и правда похожи - работа со списками, метапрограммирование. Но есть и серьезные различия. Например, в Tcl все есть строка, а не символ.
В: Могу ли я писать на Tcl функционально?
О: Можете. Tcl позволяет писать в функциональном стиле.
В: Какие парадигмы поддерживает Tcl/Tk?
О: Императивную, функциональную, объектно-ориентированную. Функциональная с версии 8.6 поддерживается очень хорошо, в ней наконец-то была правильно реализована хвостовая рекурсия. Последняя - поддерживается давно, одно из самых известных ООП-расширений XOTcl реализовывает объектно-ориентированное программирование в стиле Smalltalk... Последнее время я прихожу к мнению, что Tcl уже является языком с реализацией (пусть и частичной) всех парадигм сразу.
В: С чего начать?
О: Для начала можно ознакомиться с этой статьей и следить за обновлениями=)
В: Какие есть реализации Tcl/Tk?
О: Как таковой Tcl/Tk один, его разработку сегодня ведет Tcl Core Team, но существуют также расширения для него: стандартная реализация Tcl,XOTcl: экзотикль(расширение для ООП), iTcl (Первое ООП расширение, Inct Tcl, на нем написана iWidgets), SNIT (объектный клей для Tcl, включен в стандартную библиотеку Tcl), STOOOP (ООП-расширение написанное на Tcl, так же сегодня входит в стандартную библиотеку)
В: Какие есть "сборки"?
О: Есть официальные исходные коды, которые любой желающий может скачать с официального сайта и собрать самостоятельно. Также есть дистрибутивы от сторонних команд: ActiveState Tcl (проприетарный, есть платная версия, под все основные ОС), WinTcl (более компактный, ориентирован на работу с ХОTcl, содержит Tloona и XOTcllde, как видно из названия - под Win), TclKit (достаточно компактный дистрибутив, ориентированный на использование iTcl, обладает собран в один пакет и имеет систему управления собственным содержимым, кросс-платформенный), dqkit ("TclKit на стеродидах, есть несколько вариантов сборки, кросс),Tcl/Tk Aqua (дистрибутив заточен исключительно под MacOS). Недавно появилась реализация Tcl для .Net - Eagle.
В: Какую IDE взять?
О: Vim, Emacs - прекрасные кастомизируемые редакторы, которые расширяются в полноценную IDE. Недостаток последнего - плохая поддержка синтаксиса последних версий Tcl. (g)Vim прекрасно поддерживает синтаксис последних версий без дополнительных настроек. Под Windows - ActiveState Komodo. Tloona - IDE для Tcl/Tk написанная на Tcl/Tk. <Требуется подробное описание>. XOTcllde - IDE как ClassBrowser для Smalltalk. Ориентированна на работу с XOTcl. Visual Tcl/Tk (vtcl) - мощная среда разработки на подобии Delphi или QtCreator с возможностью редактирования кода.
В: Какую литературу можно почитать?
О: По Tcl/Tk достаточно много англоязычных туториалов. Русский нашел только один (указал вышел). Из книг могу порекомендовать "Практическое программирование на Tcl и Tk, 4-ое издание" (Б.Б.Уэлш, К.Джонс, Д.Хоббс), на английском - "Tcl and Tk Programming for the Absolute Beginner" (Kurt Wall).

Установка TclДля того, чтобы начать программировать на Tcl требуется иметь установленную виртуальную машину, которая будет обрабатывать написаннный вами код. Давайте посмотрим как ее установить:
0) Для Calculate Linux/Gentoo: emerge dev-lang/tcl, emerge dev-lang/tk, emerge dev-tcltk/tcllib
1) Для Fedora: yum install tcl tk
2) Для Ubuntu: sudo apt-get install tcl tk
3) Для Windows и MacOS: проще всего использовать бинарные дистрибутивы. Качаем любой и устанавливаем в два клика.
4) Сборка Tcl/Tk из исходников. Скачайте исходники (лежат отдельно для Tcl и отдельно для Tk) с оф.сайта и выполните следующие команды для каждого архива: 4.1 Распаковка исходных файлов: $ tar zxf имя_файла.tar.gz
4.2 Перейдите в папку командой: $ cd имя_файла && cd unix
4.3. Выполните: $ ./configure --prefix=/opt --enable-gcc
(для Тк: $ ./configure —with-tcl=../../tcl8.5a5/unix —prefix=/opt —enable-gcc)
4.4 Затем: $ make
4.5. Потом: $ make test
4.6. И в завершениии: $ make install
Для запуска интерактивной среды наберите в терминале:
$ tclsh
Должен появиться символ %.

Первая программа
Давайте напишем классическую программу "Привет слова" на Tcl. Наберите следующий код:

puts "Hello, words!"
в качестве ответа вы увидите:

Hello, words!
Поздравляем! Вы написали первую программу на Tcl. Проста, не правда ли? Давайте остановимся на команде puts. Эта команда/функция выводит текст на любое стандартное устройство ввода/вывода (в нашем случае терминал). По умолчанию после вывода текста puts перемещает курсор на начало следующей строки.

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

Команда puts по своей сути является функцией, т.к. неким элементом языка, который не только выполняет какие-либо действия, но и принимает в себя от одного до бесконечного множества аргументов (ближайший аналог - функции в математике). Если строка, которую мы выводим на экран, не была бы заключена в кавычки или фигурные скобки, интерпретатор Tcl посчитал бы каждое слово за отдельный аргумент и стал бы передавать его отдельно команде puts. Функция puts решит, что это несколько аргументов и в большинстве случаев выдаст огибку.

По своей сути командная строка в Tcl это просто список слов. Обрабатываетяс она по следующему принципу:
1. Первое слово - это сама команда (функция), которая должна быть исполнена.
2. Все следующие слова - аргументы или параметры функции.
Отметим, что в отличии от большинства языков, в Tcl командная строка заканчивается концом строки, т.е. символом начала новой строки или точкой с запятой(;). Но последний способ - не сильно хорошо, он будет понижать понятность вашего кода.

Что такое симпол новос троки? Это не видимый для вас символ, который подставляет в исходный текст вашей программы компьютер, когда нажимаете клавишу Enter. В таких языка, как Pure C он обозначается как "\n".

Так как программы бывают достаточно длинные, хорошим тоном и полезной практикой является оставлять в исходном коде комментарии к нему (некие объяснения, что делает тот или иной кусок кода вашей программы).
Комментарий - это все символы, которые идут после символа (#), который сообщает интерпретатору Tcl, что дальнейшие слова не надо исполнять.

Комментарий может быть отдельной строке или на одной строке с командой (прада этого я не рекомендую, т.к. это сложно воспринимается при изучении вашей программы другим человеком). В этом случае знак комментария будет ";#", чтобы интерпретатор не воспринял символ # как ещё один аргумент. Правда использовать данный метод для комментария любого вида - хорошая практика. В этом случае вы гарантированно не допустите случайной ошибки.

Давайте перейдем к практике. Создайте файл unit.tcl и наберите следующий тектс, а потом запустите его (команда запука - tclsh unit.tcl):

# Этот комментарий на отдельной строке
puts "Привет, Мир!"    ;# Это комментарий после команды
puts {Привет, Мир} # Добавьте точку с запятой, чтобы исправить ошибку

# Точка с запятой позволяет разместить две команды на одной строчке
puts "Это первая строка"; puts "А вот и вторая"

# Точка с запятой в кавычках не означает конца команды! Будьте внимательны
puts "Привет, Мир;"

Переменные
В любом языке программирования есть понятие "переменной", оно аналогично матиматике и будет рассматриваться в общей теориии на нашем блоге, поэтому о её сути я не буду распространятся. Коротко поясню, что переменная это слово, которое интерпретатор Tcl будет ассоциировать в вашей программы с каким-либо значением (это для удобно для того, чтобы вы могли повторно обращаться к этому значению впоследствии). Все переменные и из значения хранятся в памяти компьютера.

Виртуальная машина Tcl резервирует память когда помещаются данные в новую переменную (т.е. перемнная без значения фактически не занимает места в оперативной памяти). Обратиться к этим данным можно по имени переменной.

Для создания переменной и присвоения ей значения используется команда set. Рассмотрим пример:

set fruit "Яблоко"
В примере мы помещаем слово "Яблоко" в область памяти, на которую ссылается первый аргумент, т.е. fruit. Set всегда возвращает содержимое переменной, имя которой является первым аргументом. Таким образом, при выполнении set помещает второй аргумент в область памяти, на которую ссылается первый аргумент и затем возвращает второй аргумент.

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

set <имяПеременной> <значение>
Запомните!
а) Если значение задано, то значение переменной устанавливается равным значению.
б) Если переменная содержит только буквы, и нет скобок, то это просто скалярная переменная.
в) Если переменная задана в форме <имяПеременной>(индекс),это ячейка ассоциативного массива (о них поговорим чуть позже).
г) Команда set возвращает значение переменной.

Запустите пример, который приведен в конце урока и внимательно его прочитайте. Если вы внимательно изучили код, то увидили, что в команде set первый аргумент содержит только имя переменной, тогда как в команде puts имя переменной предварено символом $.

Иногда, когда передаётся значение переменной подпрограмме, требуется чтобы подпрограмма могда изменять данные, но это бы не повлияло на главную копию. В этом случае, ставьте $ перед именем переменной, когда вызываете подпрограмму. Таким образом, в памяти создаётся копия данных, с которой работает подпрограмма. После завершения значение основной переменной не изменяется. Это называется "Передача по значению", так как передаётся именно значение переменной.

Но иногда (например, для команды set) требуется, чтобы изменилось значение переменной. В этом случае нужно передать ссылку на область памяти, где хранится значение переменной, тогда команда сможет модифицировать данные в этом месте. В Tcl это делается НЕ добавлением $ перед именем переменной. Это называется "Передача по ссылке", так как команде передаётся ссылка.

Итак, с командой set используется просто имя переменной, поэтому передаётся ссылка. Set помещает данные из второго аргумента в область памяти, на которую ссылается первый аргумент.

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

Измените программу в примере и переходите к следующему уроку.

# Присвоение строкового значения переменной X
set X "Simple string"

# Присвоение числового значения переменной Y
set Y 10

# Вывод содержимого X и Y
puts $X
puts $Y

# Просто вывод разделителя, для удобство чтения выводимой в терминал информации
puts "..............................."

# В одной команде puts может быть выведено более одной переменной, для этого используются двойные кавычки
set label "Значение переменной Y:"
puts "$label $Y"
Последние две строки - по сути "конструктор" строки. Но о строках - мы поговорим позже. Этот урок и так получился слишком большим. Всем Удачного изучения!

P.S.: Для подготовки материала использовались материалы http://tclstudy.narod.ru, по которому я когда-то изучал данный язык.
Понравилось? Тогда вот второй урок!

Привет всем!
Знаю, что таких статей было много, но я человек с "живым" умом и люблю задаваться вопросом:"А что было бы, если?"
Давайте ответим на вопрос, а что было бы, если языки программирования были религиями?
 

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

Pure C - культ основанный на предыдущем, созданный двумя пророками, которым надоело учиться молиться в каждом храме по своему. Результат - одна из самых популярных и востребованных религий. Ее адепты одни из не многих верующих, которые не только могут написать что-то, но и прекрасно понимают как оно будет работать на том же уровне, что и Asm-культ.


С++ - очень популярный и спорный культ. Ближе к саентологии. Ввиду того, что он был создан еретиком от Pure C - похож на него и даже многие молитвы идентичны, но вобрал в себя множество сущностей из других религий, искаженных Создателем до неузноваемости и нисведенных до уровня Pure C (за что и не любим многими). Адепты считают, что С++ - религия, которая умеет и объясняет все. Противники - что это единственная религия, которая умудрилась испортить даже идеи базового культа.

Pascal - одна из реинкарнаций секты Никлауса Вирта - известного философа и идеолога различных движений, каждая из которых превосходила предыдущую по уровню развития. Считается, что "Паскаль" - религия для детей, которая готовит их к взрослой жизни. На практике - почти полный аналог Pure C.


ActionScript - квази-религия, созданная вокруг центра развлечений (аналог Джедаизма). Ввиду того, что центр устарел и вокруг понастроили множество других центров развлечений - становится не нужным, но адепты не хотят уступать "места под солнцем".



Object Pascal - православное христианство от языков программрования, несет в себе массу хороших идей, в нюансах которых часто не хотят разбирать массы. Получил особое распространение в России вместе с церковью пресвятого Delphi.

Agda - неорелигия основанная на чистом матане, которая описывает Утопию и возводит в культ сферического коня в вакууме. Особое распространение пока не получило, но дико любима математиками и всеми смежными специальностями, так как позволяет жить использую только чистые истины. Когда адепты начинают писать свои мантры - их не понимает никто.

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

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


Smalltalk - даосизм. Основа всего Дао и все есть продолжение дао и его часть. Религия настолько древняя, что мало кто помнит её, считается единственной чистым и полным отражением учения об объектах, а так же недостижимым идеалом его воплощения.

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

Haskell- дзен-буддизм, склоняется к чистым идеям матана, но не отрицает необходимости понимания других идеологий. Наиболее распространен среди матанорелигий.

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


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

C#- еретический даосизм от "Корпорации зла". Вобрал в себя идеи Java и всего, что могло бы облегчить жизнь программистам. В итоге имеет такое количество многословных молитв, какого не было даже в язычестве.


COBOL -язычество, тексты которого очень подробны. Его не любят все, но за его понимание очень хорошо платят.
 

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

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

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

Visual Basic - иудаизм, нелюбим теми, кто не умеет зарабатывать опираясь на его постулаты. Часто используется как пример всего самого плохого, хотя очень много программ реализовано на нем.

Refal - универсальная религия, которая так и не нашла отклика в сердцах. Идеи философии слишком опередили время, а развал Советского Союза (где и было основано учение) - ускорили процесс закапывания культа.

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

Lua - простой в освоении языческий культ природы, основанный на поклонении богине. Получил гораздо меньшее распространение нежели заслуживает, так как появился позже Ruby и Python.

Prolog - конфуцианство. Мудрость в чистом виде. Все понимают, что в этом есть Истина и Глубина. Но мало кто по настоящему его освоил.

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

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

Whitespace - религия в которой основой всего является пустота. Основой, идеей и единственной сущностью.

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

Приветствую! %username, ты наверняка слышал про такой язык как tcl и его графический тулкит tk. Язык отличается особой гибкостью (на мой скромный взгляд). Пока нет много времени написать об "облачной" разработке, решил написать мини-статью/мини-урок про одну из возможностей замечательного языка tcl - словарях ( причем, их я не могу вспомнить по книге "Практическое программирование на Tcl/TK", быть может просто читал старую версию). Наиболее полное описание данного типа данных, %username, ты можешь найти по ссылкe.

Немного теории - словарь в tcl это такой тип данных, которые позволяет хранить сложные упорядоченные значения по типу "ключ-значение", причем с возможностью ветвить само дерево. Иными словами - на один ключ (к примеру ID записи) может приходиться не одно значение, а еще несколько ключей со значениями. Выглядит в синтаксисе tcl это примерно так:

dict set nonUserSettings 0 title "myProgram"
dict set nonUserSettings 0 minWidth 800
dict set nonUserSettings 0 minHeight 600
dict set nonUserSettings 0 resizableX 1
dict set nonUserSettings 0 resizableY 1

Что делает данный код? Все просто - он создает словарь programSettings, который имеет атрибуты title, minWidth, minHeight, resizableX, resizableY. Причем, за счет ID элемента в словаре мы можем натирать настройки для других root-окон программ (такое может потребоваться, если вы планируете делать многооконный интерфейс).

Доступ к значению из словаря можно получить по средствам выполнения следующей команды:

dict get <имя-словаря> <атрибуты>

Давайте "нарисуем" окно Tk с помощью нашего словаря. Обычный код, выглядел бы таким образом:

wm title . "myProgram"
wm resizable . 1 1
wm minsize . 800 600
Наш код будет иметь следующий вид:

wm title . [dict get $nonUserSettings 0 "title"]
wm resizable . [dict get $nonUserSettings 0 "resizableX"] [dict get $nonUserSettings 0 "resizableY"]
wm minsize . [dict get $nonUserSettings 0 "minWidth"] [dict get $nonUserSettings 0 "minHeight"]
Что нам это даст? По своей сущности, словари (как, впрочем и все данные в tcl) - мутабельны. Следовательно могут быть переопределены. Таким образом, мы получаем окно, которое при переопределении значения, полученного из словаря, меняется. При этом перезапуск программы не требуется. Иными словами - настройки вашего GUI будут подхватываться динамически. Но, все это можно легко реализовать через список. Тогда зачем нам использовать словарь. Ну, во первых - использование словаря сделает программу более читаемой, ее данные - более систематизированными (по сути вы держите некое подобие таблицы базы данных в коде). А с другой...сейчас покажу.

Предположим, нам необходимо сделать обычное верхнее меню. Как виджет - оно имеет свою имя, а так же опцию tearOff. Для хранения настроек создадим еще один словарь:

dict set menuBarSettings 0 name mainMenuBar
dict set menuBarSettings 0 tearOff 1
Данные о типе выпадающего меню из меню-бара добавим сразу:

option add *tearOff [dict get $menu-settings 0 "tearOff"]
Так же, предположим, мы хотим дать пользователю возможность включать и отключать верхнее меню:

dict set userSettings 0 menuBar true 

А вот с отрисовкой давайте немного повременим. Описывать весь GUI вручную не имеет особого смысла, ведь у нас в арсенале очень мощный инструмент - итеративный перебор словаря по ключам и параметрам. Для меню заглавий меню создаем словарь:

dict set menuBarItems_ZeroLevel 0 name connectionItem
dict set menuBarItems_ZeroLevel 0 text_item "Connection"
dict set menuBarItems_ZeroLevel 1 name helpItem
dict set menuBarItems_ZeroLevel 1 text_item "Help"
Теперь создадим словарь, в котором будет храниться меня первого уровня (параметр parent будет обозначать id заголовка меню к которому привязан первый уровень):

dict set menuBarItems_FirstLevel 0 parent 0
dict set menuBarItems_FirstLevel 0 label "Open"
dict set menuBarItems_FirstLevel 0 command NONE
dict set menuBarItems_FirstLevel 1 parent 0
dict set menuBarItems_FirstLevel 1 label "Editt"
dict set menuBarItems_FirstLevel 1 command NONE
dict set menuBarItems_FirstLevel 2 parent 0
dict set menuBarItems_FirstLevel 2 label "Exit"
dict set menuBarItems_FirstLevel 2 command { exit; }
dict set menuBarItems_FirstLevel 3 parent 1
dict set menuBarItems_FirstLevel 3 label "About"
dict set menuBarItems_FirstLevel 3 command NONE
dict set menuBarItems_FirstLevel 4 parent 1
dict set menuBarItems_FirstLevel 4 label "Help"
dict set menuBarItems_FirstLevel 4 command NONE

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

# Создаем процедуру, которая будет "собирать" меню из словарей
proc assembleMyMenu {} {
# Так, как функция оперирует только локальными значениями переменных, то нам необходимо ввести в ее область видимости все нужные нам словари
    global userSettings
    global menuBarSettings
    global menuBarItems_ZeroLevel
    global menuBarItems_FirstLevel
# Проверяем, не выключил ли пользователь вывод верхнего меню
    if {[dict get $userSettings 0 "menuBar"]==true} {
# , если да, то:
# создаем собственно саму строку верхнего меню (обратите внимание, путь до виджета так же является "динамическим" и формируется из элемента словаря
        menu .[dict get $menuBarSettings 0 "name"]
# применяем настройки и отрисовываем строку на верхней части окна
        . config -menu .[dict get $menuBarSettings 0 "name"]
# Собственно начинается перебор. Берем словарь с заголовками меню и перебираем его
        dict for {id info} $menuBarItems_ZeroLevel {
# info - вобрал в себя ввесь массив ключей и значений. Так, как с id-шником нам собственно пока делать нечего особо, по средствам ключевого слова with формируем из данных следующий код:
            dict with info {
# Создаем непосредственно меню нулевого уровня по ключу name словаря menu-bar-items и формирую путь до виджета из menu-settings:
             menu .[dict get $menuBarSettings 0 "name"].$name
# Собственно добавляем заголовок
                .[dict get $menuBarSettings 0 "name"] add cascade -label $text_item -menu .[dict get $menuBarSettings 0 "name"].$name
# Врубаем новый итеративный цикл на подобии указанного выше, но целевым будет словарь menu-bar-items_first-level
                dict for {iter data} $menuBarItems_FirstLevel {
                    dict with data {
# Проверяем какому родительскому элементу принадлежит пункт, если истина - прорисовываем:
                        if {$id==$parent} {
# А вот тут - формируем меню второго уровня
                            .[dict get $menuBarSettings 0 "name"].$name add command -label $label -command $command
                        }
                    }
                }
            }
        }
    }
}


Полный код нашей программы:

#Подключаем туллкит
package require Tk
# Данные для настроек, не связанных с пользователем
dict set nonUserSettings 0 title "myPrograms"
dict set nonUserSettings 0 minWidth 800
dict set nonUserSettings 0 minHeight 600
dict set nonUserSettings 0 resizableX 1
dict set nonUserSettings 0 resizableY 1
# Настройки, связанные с пользователем
dict set userSettings 0 menuBar true
# Данные для настройки меню
dict set menuBarSettings 0 name mainMenuBar
dict set menuBarSettings 0 tearOff 1
# Данные для меню нулевого уровня
dict set menuBarItems_ZeroLevel 0 name connectionItem
dict set menuBarItems_ZeroLevel 0 text_item "Connection"
dict set menuBarItems_ZeroLevel 1 name helpItem
dict set menuBarItems_ZeroLevel 1 text_item "Help"
# Данные для меню первого уровня
dict set menuBarItems_FirstLevel 0 parent 0
dict set menuBarItems_FirstLevel 0 label "LogIn"
dict set menuBarItems_FirstLevel 0 command NONE
dict set menuBarItems_FirstLevel 1 parent 0
dict set menuBarItems_FirstLevel 1 label "LogOut"
dict set menuBarItems_FirstLevel 1 command NONE
dict set menuBarItems_FirstLevel 2 parent 0
dict set menuBarItems_FirstLevel 2 label "Exit"
dict set menuBarItems_FirstLevel 2 command { exit; }
dict set menuBarItems_FirstLevel 3 parent 1
dict set menuBarItems_FirstLevel 3 label "About"
dict set menuBarItems_FirstLevel 3 command NONE
dict set menuBarItems_FirstLevel 4 parent 1
dict set menuBarItems_FirstLevel 4 label "Help"
dict set menuBarItems_FirstLevel 4 command NONE
# Функция сборки меню
proc assembleMyMenu {} {
    global userSettings
    global menuBarSettings
    global menuBarItems_ZeroLevel
    global menuBarItems_FirstLevel
    if {[dict get $userSettings 0 "menuBar"]==true} {
        menu .[dict get $menuBarSettings 0 "name"]
        . config -menu .[dict get $menuBarSettings 0 "name"]
        dict for {id info} $menuBarItems_ZeroLevel {
            dict with info {
                menu .[dict get $menuBarSettings 0 "name"].$name
                .[dict get $menuBarSettings 0 "name"] add cascade -label $text_item -menu .[dict get $menuBarSettings 0 "name"].$name
                dict for {iter data} $menuBarItems_FirstLevel {
                    dict with data {
                        if {$id==$parent} {
                            .[dict get $menuBarSettings 0 "name"].$name add command -label $label -command $command
                        }
                    }
                }
            }
        }
    }
}
# Логика основной прогаммы

# Собираем программу =)
wm title . [dict get $nonUserSettings 0 "title"]
wm resizable . [dict get $nonUserSettings 0 "resizableX"] [dict get $nonUserSettings 0 "resizableY"]
wm minsize . [dict get $nonUserSettings 0 "minWidth"] [dict get $nonUserSettings 0 "minHeight"]
option add *tearOff [dict get $menuBarSettings 0 "tearOff"]
assembleMyMenu


Надеюсь, урок/статья оказалась полезной. Приятного погружения в наркоманский код tcl/tk!

Доброго времени суток, %username%!
Сегодня я хочу рассказать тебе о таком понятии как «старт-ап». Только я не буду окрашивать жизнь в розовый цвет. Впрочем, не жди и серых оттенков. В отличии от большинства обитателей «хабра» я имею профессиональное экономическое образование. И знаю что такое «старт-ап» на собственном опыте. Причем за плечами есть не только негативный или позитивный опыт. Есть и победы и неудачи. Не только мои, но и моих клиентов (некоторое время работал «на себя», но сейчас закрыл фирмы — при моих ограниченных финансах «свое дело» на должном уровне пока не реализовать). Именно об этом я и хочу рассказать. Впрочем, данная статья является, в том числе, «анализом» событий за последние два года с точки зрения человека немного понимающего в экономике. Начнем... 

«Старт-ап» как тренд
Ни для кого не секрет, что «старт-ап» является сегодня трендом, веянием моды. Что меня поражает, никто не пытается проанализировать почему так сложилось. Если ты, %usename%, собрался работать на «себя» и создавать «проект своей мечты», то подумал — кто тебе подал эту идею. Книги Джобса, Гейтса и прочих воротил бизнеса? Тогда ты скорее всего мечтатель, верящий в розовых пони и радужные берега. Люди, которые по правде долгое время работают в рамках какой-нибудь отрасли пришли туда не так случайно как кажется. У любого успешного проекта есть предпосылки. Будь то гениальный инженер, великолепный программист или серьезный капитал — это необходимо. Пойми, затратив минимум средств и сил ты не станешь легендой. И если ты сам не гений (а это скорее всего, раз ты читаешь сей труд и/или до сих пор не «выстрелил»), да и друзья у тебя такие же — то стоит задуматься где достать денег. Лучший вариант если у тебя папа/мама/тетя/дядя/etc. имеют средства и ты можешь у них попросить их. В этом нет ничего зазорного. Многие так начинали. Бизнес не для тех, кто хочет остаться чистым и отвергает постоянно помощь. Он для тех, кто может максимально быстро и выгодно приспособиться. Запомни одну вещь, раз и навсегда! Она следует из самой идеи капитализма: все что в рамках закона — честно и достойно. Все остальное не важно и не имеет значения. Идеальный предприниматель не мучается от активизации совести или прочей ерунды, ведь если не ты заработаешь на этом, то кто-то другой.

Кто же еще мог тебя спровоцировать «делать свое дело»? Статьи, «сацесс-стори таких же простых людей». А теперь задумайся. В них написано лишь то, что было «хорошего». Но никто не пишет о том, что пришлось работать без сна и как себя ощущал. На что приходилось идти, чтобы получать каждую лишнюю копейку прибыли. Наверняка многие бы хотели жить лишь за счет «своего дела» и не работать «на дядю». А теперь задумайся — почему «дядя» организовавший свое дело так много получает, а тебе дает лишь то, что причитается тебе за работу. Он работает в отличии от тебя 24 часа в сутки, его работа — быть доступным для бизнеса в любой момент своей жизни. По большому счету на первые три года ты вообще забудешь такие понятия как здоровый сон, личная жизнь или выходные. Цена успеха — отказ от самого себя на срок от трех до десяти лет. А возможно и на всю жизнь.

А теперь задумайся — кто культивирует этот тренд и главное — почему. Ответ простой — сами экономисты. Понятие «старт-ап» очень выгодно для России. У нас не развит малый бизнес (фактически его нет), а без его развития по мнению российских экономистов не создать здоровую экономику. На самом деле главная роль малых предприятий в тех же «штатах» — обслуживание заказов крупных предприятий или создание продуктов, которые удовлетворяют очень маленький рынок (крупным компаниям просто не выгодно работать на нем). Но говоря о малом бизнесе многие забывают, что цель любого малого предприятия — стать монополистом. И пусть тебе говорят, что монополизация это плохо, что с ней не создашь здоровую и эффективную экономику. Это не правда. Монополизация есть естественное состояние рынка ввиду множества факторов. Любой хочет стать «царем горы», неправда ли?.. Постоянное появление же «старт-апов» обеспечивает прибыль другим игрокам рынка (ведь все же не совсем «бесплатно» создается проект). По большому счету за счет них экономисты создают дополнительные вливания капиталов в фирмы более крупные, чем создатели проектов. Другими словами — простой Ванька, который решил стать новым королем «этих ваших интернетов» за счет своего «крутого проекта» является по большому счету «дойной коровой». На рынке выигрывают только крупные игроки. А Ваня слаб, у него нет поддержки и денег. Кстати, по такой же системе работает Forex на котором выигрывают нормальные суммы лишь те, кто имеет оборот с суммой от шести нолей. Наверняка у тебя уже зародилось недоверие к моей позиции. Хорошо, приведу пример.

Одним из первых проектов, который реализовывала моя компания был ресурс банковского автомата WebMoney для одного человека. Тот полтора года занимается выдачей микрокредитов и решил автоматизировать процесс выдачи. Естественно, что как любой нормальный «кредитодатель» он захотел вести аналитику своей деятельности. Я опущу все технические подробности реализации проекта (хотя проблем работы с WM было много, как с точки зрения документации, так и отвратительная служба поддержки, которая была не в состоянии ответить на вполне конкретные вопросы ведущего программиста), скажу лишь только то, что «старт-ап» заказчика через год с треском провалился. Причина — просто отсутствие средств. Сейчас проект закрыт, доменное имя продано другому. Естественно к нам обратились с «претензиями», так как «ожидаемого эффекта» достигнуть не удалось. После проведения некоторого несложного анализа (просмотрел «деятельность» данного проекта, в т.ч. рекламу, PR и маркетинговую стратегию) оказалось, что продвижением проекта заказчик не занимался — не хватило денег. У него было чувство, что проект начнет приносить прибыль и он через некоторое время сможет оплатить рекламу и заказать продвижение в поисковике (мы не занималась данным видом деятельности — наша специализация была исключительно техническая реализация). Что интересно — потенциал проекта был достаточно высокий. Наш продукт был сделан на более высоком уровне, чем у большинства «конкурентов» заказчика. Исходники даже предлагали выкупить за сумму в несколько раз большую люди с нормальной финансовой базой (в последствии отказались — нашли более привлекательный сегмент для инвестирования). Может многие скажут: «Да что тут нового?! Эта идея была ущербна изначально», — или: «Сам дурак — соваться в без денег не имеет смысла». С одной стороны ты будешь прав, но с другой — 99% «старт-апов» удовлетворяют те потребности, что и множество существующих продуктов. А нормальное финансирование является скорее большой редкостью (ведь мы говорим не о таких проектах, как «Хабра» или «ВКонтакте», а о «домашнем проекте» Вани, который создал в голове аналог «американской мечты»). Рынок в таких случаях просто перераспределяет деньги от тех, кто «поглупее/наивнее» к тем, кто готов за выполнение желания этого «наивняка» взять вознаграждение. Отмечу, что когда человек отказался сразу заказывать продвижение проекта в другой организации (мы советовали, там ему сделали бы 30% скидку «по знакомству»), а решил отложить его на пару месяцев после вывода проекта — я понял что продукт «не выстрелит». Скажите аморально и безнравственно было брать за это деньги? Отнюдь. Он получил урок (причем очень хороший, работа была очень не дешевый), а мы — деньги. Если бы это сделали не мы — то занялся бы кто-нибудь другой.

Выбор идей
Отложим в сторону разговор о финансировании (о нем можно распинаться часами), а поговорим лучше об идеях и Идеях. На самом деле придумать что-то принципиально новое в рамках существующих технологий невозможно. Так же не возможно создать рынок без возникновения новой потребности или больших капиталов на создание этой потребности (привет, яблочная компания! Вы лучшие в этом деле!). Поэтому давайте ответим честно на вопрос: «Могу ли я придумать что-то стоящее». Чаще всего ответ будет категоричное «нет». Успешными становятся только те проекты, которыми сможет пользоваться не только создатель и еще сотня человек. По настоящему используемые проекты становятся «постояльцами» большинства пользователей (сколько людей работают с тем же Evernote). Поэтому аудитория в 100 человек не принесет настоящей прибыли. Конечно это не так, если Ваши клиенты различные ТНК и вы разрабатываете сверхсложную систему без которой они не смогут работать. Но сделать такое вы скорее всего не сможете, будем реалистами. Тогда что делать? Придумать как удовлетворить потребность качественнее конкурента. К примеру — тот же же Windows объективно легче для использования стандартным «хомячком», чем Linux; а в ранее Mac'и были объективно проще в использовании, чем IBM PC с MS-DOS. Человек по своей природе ленив и хочет, чтобы его развлекали и делали жизнь проще. Играйте на этом. Сразу отпала половина идей? Это нормально. Большие компании имеют целые отделы, занимающиеся «генерацией идей». Поэтому даже пара «очень светлых» умов не способно «на гора» выдать идею-шедевр.

Делать же «просто подобный проект» и «плодить сущности» мягко говоря не имеет смысла. Вы не сделаете лучше, чем компания имеющая большие обороты. Даже при хорошем финансировании создавая полную копию чего-то вы сможете лишь греться в остатках лучей от конкурента. Много вы знаете дистрибутивов на базе Ubuntu? Если будет с десяток — это очень хорошо. А ведь их сотни тысяч. Их создатели что-то получают (фан, опыт, донат), но они никогда не попадут в этот десяток. Так же и твой проект — если им не будут пользоваться тысячи, то он просто не окупит вложенных в них усилий.

Наверное ты думаешь: «Да, что он может окупить? Разве что хостинг/работу художника/etc.». К сожалению я хочу расстроить — даже если ты разместил сайт на халявном (ну пусть тебе его подарил друг) хостинге, а реализацию сделал сам — все равно ты понес издержки! Ты затратил время, которое мог потратить на что-то более полезного. Именно стоимость этого времени никогда не учитывается большинством российских предпринимателей и стартаперов. Понятие «альтернативных издержек» просто выкинуто большинством со словами: «Да что я мог сделать еще полезного?» По правде много чего. Список сможешь составить для себя сам. И помни — ценность времени порой выше ценности денег (это тебе без труда докажет любой настоящий бизнесмен вкалывающий от рассвета и до рассвета). И это не актуально для тебя сейчас, скоро ты это осознаешь.

Но вернемся к выбору идей. Основную массу от провальных идей можно отделить очень просто — скажи честно, смог бы ты сам пользоваться этим каждый день не только потому, что сам это сделал. Скажем, ты навряд ли будешь пользоваться набросанным на коленке аналогом «Блокнота» вместо уютненького Vim'a. Или на вряд ли будет успех у нового «тематического форума, только со шлюхами и блэкджеком», которых и без твоего проекта over 9000. Задавайся почаще вопросом, почему выстрелили Clojure, NGNIX, Evernote, JetBrains, Facebook и почему относительно медленно идет развитие Google+ (мое личное ИМХО), не стали тортом 4-ые «Герои», вялые продали Apple Lisa и монструозного NeXT Джобса… Примеров можно подобрать много. Главное желание копаться, анализировать. Предположим все совершенно бредовое ты выбросил. Теперь самое сложное — понять, что может понадобиться человеку, обычному, в меру разумному. Иными словами — не примеряй «интересность» идеи лишь на себя. Если ты способен реализовать свой проект, придумать его, разработать — ты уже выше по знаниям большинства. Поэтому надо четко осознавать для кого ты работаешь — если твоя целевая аудитория специалисты узкого профиля, то особых проблем с освоением сложного ПО/сервиса/услуги/девайса не будет, конечно же если это будет приносить реальную пользу в работе. Но если твоя целевая аудитория — «большинство среднестатистических пользователей» (или не дай Бог школьники), то будь готов к тому, что «клиенты» не поймут сложную идею. Есть такое понятие применительно к потребителям «информационный ресурс» (очень грубый перевод с американской литературы, ближе будет наверное «ресурс восприятия»), оно обозначает способность обрабатывать и воспринимать информацию. Иными словами — не каждый способен освоить сборку Linux из исходников, но практически любая домохозяйка сможет поставить Microsoft Windows (не будем лукавить, проблем с установкой той же 7-ки практически не возникает). Или посмотри на дикую популярность «Веселой Фермы». А ведь на ее разработку было затрачено гораздо меньше, чем на тот же The Temple of Elemetnal Evil (от Troika Games), хотя рентабельность первой игры (чисто казуальной) выше во много раз.

Предположим ты даже смог отобрать идею. Теперь необходимо довести ее до воплощения и не забросить на полпути. Для этого надо не просто фанатично «творить», а скрупулезно, качественно прорабатывать каждую мелочь. Именно скучная на первый взгляд работа принесет наибольшую отдачу. До посинения вылизывать интерфейс новой программы не так интересно, как писать функционал, но именно он может оказаться решающим фактором в твою пользу, даже если функциональность пока «провисает». Для того, чтобы на проект обратили внимание — надо сделать из него «красивую конфетку», наделить его именно теми чертами, которые точно понравятся большинству потенциальных потребителей из целевой аудитории. Ведь ты наверняка тоже, как и большинство, не пользуешься Tkabber'ом, потому что «он страшный, как и весь Tk!».

Что еще можно сказать об идеях? Наверное только то, что отбору идей надо учиться у лучших. Встает вопрос: «Как?» К сожалению ответа на него у меня нет. Я сам не обладаю достаточными знаниями в этой области. Но хочу отметить, что если в основе старт-апа лежит исключительно желание получить прибыль через создания очередного дейтинга — не стоит терять времени. Подчеркиваю еще раз — любой успешный проект в той или иной степени удовлетворяет ту потребность, которая ранее не была затронута, удовлетворена. Именно поэтому те же «маки» — ПК для «недоразвитой общественности» выдержали конкуренцию с IBM-PC, Linux до сих пор существует, а идущие против этого HaikuOS (правка через пять месяцев после начала работы над статьей: хайку таки может и будет Win!, просто я тогда не понимал целей этого проекта; мнение поменял после того как посидел на сабже четыре месяца) и ReactOS не могут выйти из состояния «зародыша» (прим: мнение по поводу «реакта» стало еще хуже — создается ощущение, что цели не понятны самим создателям).

Конец?!...
Но это не конец. Работа над статьей только началась. Представленный текст лишь начало большой работы. Во что она выльется — пока трудно сказать. Но, продолжение следует.

Кстати, данная статья взята с ХабраХабр, с разрешения автора!

Приветствую всех, кто нашел наш блог!

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

Основная проблема для всех программистов в Российской Федерации - почти полное отсутствие качественного профильного образования. В настоящий момент ситуация немного улучшилась (спасибо Microsoft за программу поддержки студентов, благодаря чему сегодня молодых программистов все же учат не Fortran/Prolog/Delphi, а вполне востребованному языку - C#), но она все равно оставляет желать и желать лучшего.

Что огорчает - в России сегодня есть два вида ресурсов, которые могли бы помочь обычному человеку стать программистом или ИТ-специалистом иного рода:

• Исключительно гиковские, такие как LOR или OpenNet : искать помощи на них не приходится. Если первый - сборище интернет-троллей, теоретиков и гуманитариев (хотя есть и на нем толковые люди), то второй - простой информационный портал, для тех кто "уже в теме". Дизайн обоих ресурсов, кстати говоря, оставляют желать много и много лучшего...
• Исключительно коммерческие, такие как всем известный "Хабр", на котором хоть и много полезного материала, но с каждым днем он всё больше ставновится "глянцевым журналом", а не "клубом по интересам". Собственно для того, чтобы не допустить этого для данного проекта и был выбран формат интернет-блога, а не какого-то отдельного полноценного информационного ресурса.

Куда деваться тому, кто только принял решение стать программистом? Очень просто - добро пожаловать к нам! Надеемся вам будет интересно.