Ну это менее интересная задача. И требует только подхода в сжатии информации. В оригинальной же задаче все намного интереснее — тут надо пораскинуть мозгами.
Как я понимаю метод init(data) запускается один раз и дальше запускается только test(word) много много раз? Или же на каждую сотню-блок — все по новой? Сколько будет минимально блоков?
Отличная статья! У меня подобная идея была, но с целью изучать разные алгоритмы и ИИ. К тому же использовать виртуальную реальность в виде открытого мира игры какой нить — это отличная идея ) А потом перенести все в реальный мир.
Ну лично я не поклонник командной строки, прописывать каждый файл который надо скомпилить — это тот еще ад. Проще указывать по необходимости из файла в фаил.
Да безусловно Haxe в данных вопросах лучше. Он делался по образу и подобию AS3. Но он тоже не лишен недостатков — а их у него очень много. И да я пишу на Haxe сейчас. Просто тут обсуждение TypeScript и хотелось бы узнать побольше о нем )
Недавно изучал TypeScript. Выводы в основном положительные. Но есть ряд вещей которые я так и не понял:
1. Как импортировать другой файл TypeScript, что бы он вкомпиливался в результирующий файл? Т.е. как в обычных языках — пишешь импорт такой то класс и все. А вот с TypeScript такое не пройдет — надо указывать в html дополнительно этот файл. Или есть способ проще и элегантнее без большой писанины?
2. Приватные переменные только проверяются на стадии компиляции — но на самом деле они публичные и если предок и наследник имеют приватную переменную с одним и тем же именем — будет просто ошибка компиляции. Это как то не продумано.
Привет из Великого Новгорода! ) Было очень приятно увидеть тебя на хабре! Твоя история достойна уважения. И я очень раз за тебя! Осознание того кем ты хочешь стать по настоящему приходит позже, поступления в какой либо ВУЗ. Я к примеру учился на инженера механика и успешно закончил магистратуру. Но уже тогда работал программистом с 4-го курса. К сожалению, многие программисты останавливаются на шаблонном «Software design patterns» программировании. Самоучки же — они просто фанаты своего дела, им нет границ, они готовы решать нетривиальные задачи.
Ну по поводу 1 имеется ввиду вес приложения не должен быть неоправданно огромным например более 10 мб. Так же если учесть что другие требующие SDK и Runtime уже установлены. Т.е. вес чистого приложения. Например ставить полную Visual Studio 3 ГБ только для того, что бы редактировать JavaScript это как базукой по мухе.
По поводу 9 панель ошибок достаточно удобна в плане осознания сколько их, и видно текстовое описание ошибки. Конечно можно сделать выделение места ошибки прямо в коде. А панель естественно можно будет скрыть.
Тормознутость. Да начав делать свой редактор, теперь я понимаю сколько всего должен делать редактор. Есть отличный пример работающий на моем ноуте — FlashDevelop, не смотря на то что написан он на .NET он очень шустрый и ближе к тому, что я хочу для js.
Вообщем я решил сделать эксперимент — сделать свой редактор, и если он будет тормоз как и эти гиганты то я буду скромно помалкивать. Иначе выложу в опенсорс. Стараюсь не использовать сторонние библиотеки — только самые проверенные. Почти все алгоритмы пишутся с нуля, в целях изучения проблем и понятия как их можно оптимизировать.
Не устраивает — громоздкость, тормознутость, платность, куча фич которые мне лично не нужны. Это касается всех крупных оффлайн IDE.
Забыл написать про то как я вижу продукт:
1. Маленький вес приложения.
2. Быстрая работа самого редактора — сделал действие — все должно моментально обновиться.
3. Если же нужно больше времени на какую то фичу, процесс выполняется параллельно — не должно ничего тормозить, зависать.
4. Полностью настраиваемая подсветка синтаксиса.
5. Редактор должен уверенно работать с огромными файлами — несколько тысяч строк.
6. Настраиваемый скин редактора — что бы можно было настроить цвета под себя.
7. Панель проектов не должна содержать проекты, а просто указывать на заданные директории.
8. Должна быть панель со структурой кода, которую тоже можно настроить под свои нужны, например отображать структуру или только список функций. Как ни странно с этим плохо у многих легких редакторов.
9. Должна быть панель ошибок в коде.
10. Быстрый поиск — выделил текст, нажал F3 и скачешь по совпадениям в текущем файле. Без дополнительной волокиты с панелью поиска.
11. Умный автокомплит, не просто по словам, т.е. должен быть анализ «окружения», функций, локальных переменных, классов.
12. Генерация кода, в различных местах жмешь одну комбинацию клавиш и предлагаются варианты для генерации.
13. Сниппеты(заготовки). По крайней мере все циклы, условия. Нажал комбинацию клавиш — выбор выражения которое надо создать.
14. Рефакторинг. Например, переименовать переменную или функцию.
15. Форматирование кода. Нажал комбинацию и код в удобном читабельном виде.
16. Сжатие js кода. По возможности, что бы было прямо в редакторе без плагинов и прочего.
Недавно решил поискать хорошее быстрое IDE для js. Пересмотрел кучу оффлайн и онлайн редакторов. Наткнулся на Cloud9 IDE — на данный момент одно из самый лучших на мой взгляд. Багов не нашел ибо мало пользовался. Все веселье началось когда я захотел поставить эту IDE локально на Windows. После недельных танцев с бубном IDE запустилось, но вылезла ошибка с settings. Исправить пока не удалось. И я благополучно забил на это, вернувшись обратно в тормозную Visual Studio.
Но остался осадок красивого и быстрого IDE. В итоге на досуге пишу сейчас свой редактор на Adobe AIR (AS3). И будет он оффлайн, и будет он с теми фичами которые мне нужны, и будет он быстрым.
ИМХО онлайн редакторы нужны только для случаев, когда надо что то быстро подправить, а нормальных инструментов под рукой нет.
По поводу разного размера экрана устройств и векторной графики флеша.
1. Делаем всю графику в векторе. Меньший вес, возможность получить нужного качества BitmapData в рантайме.
2. При первой загрузке приложения запускаем кеширование под размер устройства. Для этого используем BitmapData.draw(object:DisplayObject):void.
3. Сохраняем все картинки на диск устройства. Сам не пробовал — но думаю тут проблем не должно быть.
4. Далее при последующих стартах приложения — грузим заранее подготовленную битмап графику. И рисуем ее либо через CPU или же через GPU.
Конечно для такого простого проекта как в данной статье — смысла нет так заморачиваться.
Кстати в Adobe Flash SC5.5 Появилась возможность при компиляции переводить выбранные MovieClip в битмап. Т.е. в редакторе вектор — компилируем — в SWF — а там битмап.
По поводу разных пропорций экрана — можно сделать умный скейл. Конечно придется ручками писать. Например для кнопок использовать aligment. А фон растягивать с помощью scale9grid.
Тут обсуждается работа с иностранными фирмами. Поэтому фирма иностранная. Форма фирмы LTD (по моему аналог — ООО по нашему). Договор еще не оформлен. Процент от фирмы еще никак не оформлен. Все пока на словах и устной договоренности. Я буду являться как соучередитель.
Как я понимаю метод init(data) запускается один раз и дальше запускается только test(word) много много раз? Или же на каждую сотню-блок — все по новой? Сколько будет минимально блоков?
1. Как импортировать другой файл TypeScript, что бы он вкомпиливался в результирующий файл? Т.е. как в обычных языках — пишешь импорт такой то класс и все. А вот с TypeScript такое не пройдет — надо указывать в html дополнительно этот файл. Или есть способ проще и элегантнее без большой писанины?
2. Приватные переменные только проверяются на стадии компиляции — но на самом деле они публичные и если предок и наследник имеют приватную переменную с одним и тем же именем — будет просто ошибка компиляции. Это как то не продумано.
Пробовал в Visual Studio 2015
А можно ли создавать более сложные объекты?
Хотя вот здесь нашел примеры
msdn.microsoft.com/en-us/library/bb384090.aspx
msdn.microsoft.com/ru-ru/library/bb384061.aspx
Например
Или коллбеками:
По поводу 9 панель ошибок достаточно удобна в плане осознания сколько их, и видно текстовое описание ошибки. Конечно можно сделать выделение места ошибки прямо в коде. А панель естественно можно будет скрыть.
Тормознутость. Да начав делать свой редактор, теперь я понимаю сколько всего должен делать редактор. Есть отличный пример работающий на моем ноуте — FlashDevelop, не смотря на то что написан он на .NET он очень шустрый и ближе к тому, что я хочу для js.
Вообщем я решил сделать эксперимент — сделать свой редактор, и если он будет тормоз как и эти гиганты то я буду скромно помалкивать. Иначе выложу в опенсорс. Стараюсь не использовать сторонние библиотеки — только самые проверенные. Почти все алгоритмы пишутся с нуля, в целях изучения проблем и понятия как их можно оптимизировать.
Забыл написать про то как я вижу продукт:
1. Маленький вес приложения.
2. Быстрая работа самого редактора — сделал действие — все должно моментально обновиться.
3. Если же нужно больше времени на какую то фичу, процесс выполняется параллельно — не должно ничего тормозить, зависать.
4. Полностью настраиваемая подсветка синтаксиса.
5. Редактор должен уверенно работать с огромными файлами — несколько тысяч строк.
6. Настраиваемый скин редактора — что бы можно было настроить цвета под себя.
7. Панель проектов не должна содержать проекты, а просто указывать на заданные директории.
8. Должна быть панель со структурой кода, которую тоже можно настроить под свои нужны, например отображать структуру или только список функций. Как ни странно с этим плохо у многих легких редакторов.
9. Должна быть панель ошибок в коде.
10. Быстрый поиск — выделил текст, нажал F3 и скачешь по совпадениям в текущем файле. Без дополнительной волокиты с панелью поиска.
11. Умный автокомплит, не просто по словам, т.е. должен быть анализ «окружения», функций, локальных переменных, классов.
12. Генерация кода, в различных местах жмешь одну комбинацию клавиш и предлагаются варианты для генерации.
13. Сниппеты(заготовки). По крайней мере все циклы, условия. Нажал комбинацию клавиш — выбор выражения которое надо создать.
14. Рефакторинг. Например, переименовать переменную или функцию.
15. Форматирование кода. Нажал комбинацию и код в удобном читабельном виде.
16. Сжатие js кода. По возможности, что бы было прямо в редакторе без плагинов и прочего.
Остальное все стандартное.
Но остался осадок красивого и быстрого IDE. В итоге на досуге пишу сейчас свой редактор на Adobe AIR (AS3). И будет он оффлайн, и будет он с теми фичами которые мне нужны, и будет он быстрым.
ИМХО онлайн редакторы нужны только для случаев, когда надо что то быстро подправить, а нормальных инструментов под рукой нет.
1. Делаем всю графику в векторе. Меньший вес, возможность получить нужного качества BitmapData в рантайме.
2. При первой загрузке приложения запускаем кеширование под размер устройства. Для этого используем BitmapData.draw(object:DisplayObject):void.
3. Сохраняем все картинки на диск устройства. Сам не пробовал — но думаю тут проблем не должно быть.
4. Далее при последующих стартах приложения — грузим заранее подготовленную битмап графику. И рисуем ее либо через CPU или же через GPU.
Конечно для такого простого проекта как в данной статье — смысла нет так заморачиваться.
Кстати в Adobe Flash SC5.5 Появилась возможность при компиляции переводить выбранные MovieClip в битмап. Т.е. в редакторе вектор — компилируем — в SWF — а там битмап.
По поводу разных пропорций экрана — можно сделать умный скейл. Конечно придется ручками писать. Например для кнопок использовать aligment. А фон растягивать с помощью scale9grid.
хрен кто
Так что пример будет.