0
Дорогувато, однак думаю може бути вигіднішим за інши хмари. При цьому в деяких випадках буде набагато зручніше.
0
Давно ж це було. Саме після її перегляду я й почав користуватись git'ом. :)
+1
О радий побачити гарну доповідь українською мовою :) Та ще й побачити людину, що стоїть за Розробкою :)
0
Використовував. Перейшов на Python/Django. Повертатись не хочу :) На php взагалі. Якби повертався, то повертався б на Yii або CodeIgniter.
0
Ех… Коли вже ж об’єднають код Unladen Swallow з Python 3 — обіцяють jit зі значним прискоренням.
Все ніяк не дійдуть руки до того, щоб нормально розібратись з 2.7 та 3.1 :(
Все ніяк не дійдуть руки до того, щоб нормально розібратись з 2.7 та 3.1 :(
+1
Трошки не зрозумів питання :( Чи є в мене ще посилання на подібні матеріали? Здається щось було — якщо найду то обов’язково поділюсь.
0
Трошки не зрозумів питання :(
0
Так в мене ж анологічно. Стільки часу витратив марно і стільки ночей недоспав :)
0
Дякую.
Мені теж було приємно з Вами поспілкуватись :)
Мені теж було приємно з Вами поспілкуватись :)
+1
1. Та жартую я :) Дивився з тиждень тому одне відео, де творець scriptaculous показував цей простий та веселий фінт.
Сам з подібною «проблемою» зіткнувся лише одного разу: треба було з функції її ім’я визначати. З AJAX запитом передавати на сервер ім’я callback'у, щоб відповідь яка приходить у вигляді javascript приходила не просто так, а сама себе передавала як параметр тому самому callback'у. Отакий XSS-костиль для чату, написаного на nodejs, який крутиться на сабдомені основного проекту. Але це одиничний випадок — неприємно, однак вирішується один раз, а потім код зберігається в надійному місці :)
Раніше доречі в Сафарі (здається 3 чи 4), при додаванні тегу script через appendChild завантаження не відбувалось, тільки через document.write. А потім в 5ій версії я довго не міг зрозуміти, чому такий чудовий костиль перестав працювати і не міг нічого вигадати натомість — вже потім перевірив, чи працює appendChild і здивувався :)
2. Ну ось зараз в специфікації js вводять forEach, map та інше :). Ну то таке — я звик до батарейок в комплекті, тому мова без ліб, це вже якась недомова :)
3. Про закривати тег script я вже якось змирився, а спочатку ніяк не міг.
Сам з подібною «проблемою» зіткнувся лише одного разу: треба було з функції її ім’я визначати. З AJAX запитом передавати на сервер ім’я callback'у, щоб відповідь яка приходить у вигляді javascript приходила не просто так, а сама себе передавала як параметр тому самому callback'у. Отакий XSS-костиль для чату, написаного на nodejs, який крутиться на сабдомені основного проекту. Але це одиничний випадок — неприємно, однак вирішується один раз, а потім код зберігається в надійному місці :)
Раніше доречі в Сафарі (здається 3 чи 4), при додаванні тегу script через appendChild завантаження не відбувалось, тільки через document.write. А потім в 5ій версії я довго не міг зрозуміти, чому такий чудовий костиль перестав працювати і не міг нічого вигадати натомість — вже потім перевірив, чи працює appendChild і здивувався :)
2. Ну ось зараз в специфікації js вводять forEach, map та інше :). Ну то таке — я звик до батарейок в комплекті, тому мова без ліб, це вже якась недомова :)
3. Про закривати тег script я вже якось змирився, а спочатку ніяк не міг.
0
1. Ну то все дійсно прив’язка до браузера більше, ніж виконання самого javascript. Хоча згадалось, что Firefox має любов до оптимізації коду і якщо створити функцію function t() { return 1+1; } і вивести її код, то отримаємо: return 2; Це не за стандартом і дуже заважає працювати всім :)
2. Стосовно Java — все прописано у стандартах мови, тобто вся стандартна бібліотека вважається частиною мови.
3. Та не бачу причин, чому динамічне завантаження бібліотек не могли б бути частиною мови. Java та Python теж можуть динамічно завантажувати бібліотеки :)
Ну це теж забаганка така: в приципі просто зручніше було б написати: from 'https://ajax.googleapis.com/ajax/libs/jquery/1.3.2/jquery.min.js' import JQuery as $;
аніж додавати тег script чи спочатку завантажити якусь лібу для цього, а потім за допомогою неї вже щось робити :)
6. Та нічого страшного немає, однак он WebGL на підході, а усілякі любителі Gamedev зазвичай зі світу С і будуть шукати тут Threads, а не кооперативну багатозадачність, яку ще реалізувати треба. :)
2. Стосовно Java — все прописано у стандартах мови, тобто вся стандартна бібліотека вважається частиною мови.
3. Та не бачу причин, чому динамічне завантаження бібліотек не могли б бути частиною мови. Java та Python теж можуть динамічно завантажувати бібліотеки :)
Ну це теж забаганка така: в приципі просто зручніше було б написати: from 'https://ajax.googleapis.com/ajax/libs/jquery/1.3.2/jquery.min.js' import JQuery as $;
аніж додавати тег script чи спочатку завантажити якусь лібу для цього, а потім за допомогою неї вже щось робити :)
6. Та нічого страшного немає, однак он WebGL на підході, а усілякі любителі Gamedev зазвичай зі світу С і будуть шукати тут Threads, а не кооперативну багатозадачність, яку ще реалізувати треба. :)
0
1. По-перше, сімейство IE браузерів (там і стилі, і події реалізуються інакше). По-друге, різні назви об’єктів в DOM (хоча б починаються з 'object HTML' закінчується на 'Element' :)). По-третє, особливості роботи з таймером.
2. Чому ж? В java collection framework вбудований (дуже потужний), в Python ітератори та генератори — окрема техніка програмування досить потужна та цікава.
3. а) Багато зайвого коду, все ж у тих самих Java/Python з цим значно зручніше (особливо у Python: from import ). А тут десь var прогавити і можно довго шукати, чому ж тут змінна приймає таке значення.
б) Завантажувати бібліотеки додаткові динамічно — може викликати проблеми, якщо вони спочатку не були для цього написані (тобто звичайним набором функцій). Для цього треба або використовувати або готові бібліотеки, або виникають деякі костилі (зі старими версіями браузерів).
4. Я точно на пам’ятаю. Щось зі старих браузерів.
5. Я ще про мотлох, на який можна натрапити, якщо перебирати властивості через for in. Доводиться використовувати hasOwnProperty і т.д. Наприклад додали inArray і можна забути навіть про перебір масиву через for in.
6. Тож і недолік його як ігрової платформи: треба створювати свою кооперативну багатозадачність, уникати усіляких алертів, ексепшенів, синхронних операцій та обчислень, які потребують багато часу (розбивати їх на меньші та виконувати порціонально), тому що всі вони можуть заблокувати інші задачі.
8. Ні я не прихильник ідеї перевантаження в javascript. А от іменовані параметри зі значеннями за замовчуванням були б корисними та зручними, тому що
function t(a, b, c) {
if (!c) c = 3;
if (!b) b = 2;
if (!a) a = 1;
}
виглядає не зовсім приємно. {} заповнений вхідними даними від таких конструкцій також не позбавляє — додає лише іменованість.
9. Я про другий варіант.
Хоча за останні 5ть років ситуація змінилась дуже сильно на користь JavaScript (хоча Array нарешті отримав у нових браузерах forEach, map та ряд інших методів для роботи з колекціями), однак ще далека від ідеала, та ускладнюється присутністю на ринку старих моделей браузерів.
2. Чому ж? В java collection framework вбудований (дуже потужний), в Python ітератори та генератори — окрема техніка програмування досить потужна та цікава.
3. а) Багато зайвого коду, все ж у тих самих Java/Python з цим значно зручніше (особливо у Python: from import ). А тут десь var прогавити і можно довго шукати, чому ж тут змінна приймає таке значення.
б) Завантажувати бібліотеки додаткові динамічно — може викликати проблеми, якщо вони спочатку не були для цього написані (тобто звичайним набором функцій). Для цього треба або використовувати або готові бібліотеки, або виникають деякі костилі (зі старими версіями браузерів).
4. Я точно на пам’ятаю. Щось зі старих браузерів.
5. Я ще про мотлох, на який можна натрапити, якщо перебирати властивості через for in. Доводиться використовувати hasOwnProperty і т.д. Наприклад додали inArray і можна забути навіть про перебір масиву через for in.
6. Тож і недолік його як ігрової платформи: треба створювати свою кооперативну багатозадачність, уникати усіляких алертів, ексепшенів, синхронних операцій та обчислень, які потребують багато часу (розбивати їх на меньші та виконувати порціонально), тому що всі вони можуть заблокувати інші задачі.
8. Ні я не прихильник ідеї перевантаження в javascript. А от іменовані параметри зі значеннями за замовчуванням були б корисними та зручними, тому що
function t(a, b, c) {
if (!c) c = 3;
if (!b) b = 2;
if (!a) a = 1;
}
виглядає не зовсім приємно. {} заповнений вхідними даними від таких конструкцій також не позбавляє — додає лише іменованість.
9. Я про другий варіант.
Хоча за останні 5ть років ситуація змінилась дуже сильно на користь JavaScript (хоча Array нарешті отримав у нових браузерах forEach, map та ряд інших методів для роботи з колекціями), однак ще далека від ідеала, та ускладнюється присутністю на ринку старих моделей браузерів.
+1
Радію за Python та Lisp, здивований падінням JavaScript у світлі популярності NodeJS
0
Писали і продовжуют писати. Та ще й кодом та інструментами з людьми діляться… Цілі епохи… Навіть книжки написані та фільми зняті за мотивами творчості цієї команди.
(якось захотілось в ту епоху коли інтернет 33 Кб коштував дорого, а Pentium 2 здавався чимось надзвичайним)
(якось захотілось в ту епоху коли інтернет 33 Кб коштував дорого, а Pentium 2 здавався чимось надзвичайним)
0
1. Різна поведімка в різних js-двигунцях (як в браузері так і для rhine/nodejs).
2. Працювати з колекціями можливо комфртно тільки за допомогою фреймворків
3. Простори імен, що реалізуються як об’єкти, контроль завантаження коду (знову ж тільки через фреймворки).
4. Неадекватна поведінка для масивів у деяких двигунцях (маю на увазі: [1, 2, 3,] — може бути смертельним)
5. Всі об’єкти походять від Object (в тому числі й ті, що використовуються як простори імен), тому "іноді" в них опиняється купа зайвого мотлоху.
6. Все виконується в рамках одного потоку, тобто обробляти події клавіатури, миші, данні з мережі та ще й щось обраховувати може бути проблематичним.
7. == та === :)
8. Агрументи функцій (де параметри за замовчуванням чи перевантаження? arguments — зовсім не зручно використовувати)
9. Виникають складності з визначенням типів.
список можна продовжувати…
2. Працювати з колекціями можливо комфртно тільки за допомогою фреймворків
3. Простори імен, що реалізуються як об’єкти, контроль завантаження коду (знову ж тільки через фреймворки).
4. Неадекватна поведінка для масивів у деяких двигунцях (маю на увазі: [1, 2, 3,] — може бути смертельним)
5. Всі об’єкти походять від Object (в тому числі й ті, що використовуються як простори імен), тому "іноді" в них опиняється купа зайвого мотлоху.
6. Все виконується в рамках одного потоку, тобто обробляти події клавіатури, миші, данні з мережі та ще й щось обраховувати може бути проблематичним.
7. == та === :)
8. Агрументи функцій (де параметри за замовчуванням чи перевантаження? arguments — зовсім не зручно використовувати)
9. Виникають складності з визначенням типів.
список можна продовжувати…
0
OpenGL в бровсері? Можна і java використовувати, замість флешу. Хоча java-плагін менш розповсюджений за флеш, однак з точки зору набору бібліотек, потужності самої мови (вірніше віртуальної машини, що дозволяє виконувати програми написані мовами Java, Scala, Groovy, JPython, JRuby, Clojure) я думаю настільки очевидні, що тут ActionScript якось бідненько виглядає.
Хотілось би побачити ще й WebGL — поки-що в щоденних білдах FF4 для Ubuntu він ще не працює. Особисто я між ActionScript та JavaScript обираю старого знайомого JavaScript — мова більш гнучка та лаконічна, хоча й має ряд своїх недоліків та трошки незвична для програмістів на C++/Java. Однак в мене питань та нарікань синтаксис ActionScript викликав не менше.
Хотілось би побачити ще й WebGL — поки-що в щоденних білдах FF4 для Ubuntu він ще не працює. Особисто я між ActionScript та JavaScript обираю старого знайомого JavaScript — мова більш гнучка та лаконічна, хоча й має ряд своїх недоліків та трошки незвична для програмістів на C++/Java. Однак в мене питань та нарікань синтаксис ActionScript викликав не менше.
+1
Ніяка не альтернатива. Особливо якщо вся ця краса для роботи вимагатиме пропорційно тому, як зараз флеш для банерів: на 4ьох ядрах звісно все непогано, якщо не запускати паралельно серйозне ПЗ, що саме по собі може їсти процесорний час.
А так:
1. Ніхто ще нічого з приводу Flash як 3D API сказати не може. Наскільки воно буде зручним? Мені особисто ActionScript здається потворним як мова програмування. А з OpenGL я можу обрати практично будь-яку мову: C/C++, Java, Python — ці мови однозначно мають можливості роботи з OpenGL (сам працював).
2. А чи буде Flash достатньо сучасним: різноманітні шейдери і т.п.
3. Хто дасть аналоги всього того інструментарію та документації, що існує для OpenGL: десятки чи навіть сотні безкоштовних та платних двигунців, купа бібліотек, купа документації прикладів. Чим там завантажувати файли десятків форматів моделей, що розповсюджені зараз?
4. Невідомо коли це таки опиниться на наших десктопах (особливо в Linux).
А так:
1. Ніхто ще нічого з приводу Flash як 3D API сказати не може. Наскільки воно буде зручним? Мені особисто ActionScript здається потворним як мова програмування. А з OpenGL я можу обрати практично будь-яку мову: C/C++, Java, Python — ці мови однозначно мають можливості роботи з OpenGL (сам працював).
2. А чи буде Flash достатньо сучасним: різноманітні шейдери і т.п.
3. Хто дасть аналоги всього того інструментарію та документації, що існує для OpenGL: десятки чи навіть сотні безкоштовних та платних двигунців, купа бібліотек, купа документації прикладів. Чим там завантажувати файли десятків форматів моделей, що розповсюджені зараз?
4. Невідомо коли це таки опиниться на наших десктопах (особливо в Linux).
0
Мої перші спроби користуватись Linux були років 7 тому з Red Hat, а потім були Mandriva, SuSe. Але основною системою Linux став лише після того, як я попрацював з Ubuntu на початку 2006го. Після того намагався користуватись FreeBSD, Gentoo, Fedora, Debian.
На серверах часто зустрічаюсь з CentOS (суцільний жах:)), трошки сустрічався з AltLinux, AspLinux, бавився з Solaris, QNX, Plan9. Однак мені Ubuntu залишається найближчою.
На серверах часто зустрічаюсь з CentOS (суцільний жах:)), трошки сустрічався з AltLinux, AspLinux, бавився з Solaris, QNX, Plan9. Однак мені Ubuntu залишається найближчою.
0
з приводу IE 9, так його «повна підтримка сучасних веб-стандартів» так і залишається міфом та нездійснонею обіцянкою компанії Майкрософт.
На жаль, Firefox теж не є ідеальним в цьому сенсі. Будемо сподіватись, що з версії 4 будуть підтримуватись не лише WebGL (в доцільності якого особисто я сумніваюсь), але й ті CSS animations/transformations, якоми так хизується Safari і які частково реалізовані в Chrome. IE мабуть до 11 версії не будуть мати повної підтримки всього цього набору технологій.
На жаль, Firefox теж не є ідеальним в цьому сенсі. Будемо сподіватись, що з версії 4 будуть підтримуватись не лише WebGL (в доцільності якого особисто я сумніваюсь), але й ті CSS animations/transformations, якоми так хизується Safari і які частково реалізовані в Chrome. IE мабуть до 11 версії не будуть мати повної підтримки всього цього набору технологій.
GrAndSE