четвер, 30 грудня 2010 р.

scrollRect, mask <=> size etc

переважно, коли йдеться про маски і скролректи народ жаліється або на те, що після їх застосування на об'єкт, неможливо взяти оригінальний розмір об'єкта, або на те, що неможливо взяти актуальний видимий розмір об'єкта і всіх контейнерів, які його містять.

про маски: якщо потрібно знати, який видимий розмір об'єкта, і взагалі якщо маска квадратна - використовуйте скролрект. об'єкт, на який наклали маску, буде завжди повертати свій оригінальний а не видимий розмір. та щей маска виїдає більше ресурсів компа, ніж скролрект.
обговорення цього питання на ruFlash google group, ще одне корисне обговорення масок
як на мене, маску краще додавати в парент маскованого об'єкта, ато потім можна заплутатись з координатами.

scrollRect. вродь як класна, зручна і корисна фіча - працює шустріше, не потрібно мувати контент, після її накладення об'єкт повертає свій видимий розмір (а повний його розмір можна брати, загорнувши його в контейнер і скролрект напускати на контейнер, але є народ, який видумує і інші рішення), тільки є одна підй... адобівська бага під 10м плеєром - в перші 1-30 мілісекунд (в залежності від потужності машини, на якій флешка крутитьсся) після зміни scrollRect об'єкта, його розміри залишаються попередніми. так що, поки-що любе звернення до розмірів замаскованого scrollRect-ом об'єкта робимо по таймеру, і всі дружно йдем і голосуєм за фікс цього бага (ато там всього 11 голосів).

понеділок, 27 грудня 2010 р.

а тепер по ділу

головний клас проекту:

public class Main extends Sprite {


 public function Main(): void {
  if(stage) {
   init();
  } else {
   addEventListener(Event.ADDED_TO_STAGE, init);
  }
 }


 private function init(event: Event = null): void {
  removeEventListener(Event.ADDED_TO_STAGE, init);
  
  var test: TestChild = new TestChild();
 }
}





клас TestChild


public class TestChild extends TestParent {


 public function TestChild() {
  data = [1, 2, 3, 4];
  arr = [11, 22, 33, 44];
  obj = {name: "Test", value: "ttt"};
  intNum = 24;
  floatNum = Math.PI;
  point = new Point(7, 13);
  str = "Svitovyda";


  super();


  trace(this, data);
  trace(this, arr);
  trace(this, obj);
  trace(this, intNum);
  trace(this, floatNum);
  trace(this, point);
  trace(this, str);
 }
}





клас TestParent


public class TestParent {
 protected var data: * ;
 protected var arr: Array;
 protected var obj: Object;
 protected var intNum: int;
 protected var floatNum: Number;
 protected var point: Point;
 protected var str: String;


 public function TestParent() {
  trace(data);
  trace(arr);
  trace(obj);
  trace(intNum);
  trace(floatNum);
  trace(point);
  trace(str);
 }
}





результат запуску в трейсі:



undefined
11,22,33,44
null
24
NaN
(x=7, y=13)
Svitovyda
[object TestChild] undefined
[object TestChild] 11,22,33,44
[object TestChild] null
[object TestChild] 24
[object TestChild] NaN
[object TestChild] (x=7, y=13)
[object TestChild] Svitovyda



якби мені хтось пояснив це, була б дуже вдячна. а так: Flash - #@%$%@^%$.


а ще скажу банальність: 9scaleGrid - #@%$%@^%$.
і лінії - теж.


гррррр!

не екшинскриптове

а хардварне

як ви думаєте, якщо така рижа блондинка, як я, візьметься розбирати непрацюючу колонку (друга працює, на поломаній - всі регулятори, входи для штекера і вихід на другу - і все це працює, а сама колонка мовчить. генєратор работаєт но нє гєнєріруєт, да) і спробує там знайти щось, від чого ця колонка не працює - з цього хоч щось получиться? ну, крім ще одного смішного поста сюди, я маю на увазі...

пробувала підключити до свого робочого ноута дома клавіатуру. PS/2 (ну так вже сталося. і не питайте мене де я дістала перехідник з usb на ps/2 за 15 грн і як перевіряла його дієздатність, підключивши через нього і мій старий перехідник з ps/2 на usb флешку - працює). а вінда - сьома (погугліть windows 7 + PS/2, ага). клавіатура щей старезна і майже безімянна - мітсумі. короч я згадала казку про кощеєву смерть, коли гуглила за драйвером під він7 для неї: смерть в голці, голка в яйці, яйце в качці качка ще там в комусь... сторінки і форумні пости датою до 2008, туманне посилання на щось, де ще туманніше посилання на мітсумівський ftp-шник (толку з мітсумівського офсайту - самі розумієте, а ні - зайдіть і зрозумієте), доступ до якого, мабуть, закритий ще з 2008 в кращому випадку. знайшла якусь ходилку по закритих фтп-шніках, добралась до папки з дровами - а там купа екзешників з кучерявими іменами. і доступ на скачування все-таки закритий. до кінчика голки я таки недобралась ))))
прогуглила на тему він7+пс2, проінсталювала купу всякого різного - толку нуль.

можна, звичайно, купити нормальну клаву. але, по-перше, мені і так вже потрібен монік (згорів ще у львові до переїзду, системник я вже перевезла), колонки (як видно з першої частини цього поста), wi-fi роутер (я ще і досі дома не підключилась до нету), і по ходу свій власний ноут. і взагалі в мене навіть холодильника робочого дома зараз нема ))). а ще і якось не спортивно виходить - стільки часу потратити на рішення проблеми і забити )))))

четвер, 9 грудня 2010 р.

Всяке різне

Пишуть мені в LinkedIn пропозицію віддаленої одноразової роботи, 40-50 годин. Мене не цікавить віддалена робота (я загружена на повну на поточному місці роботи, яким взагалі дуже задоволена), але от часом дивуюсь: дописувачка, скажемо так, кириличномовна, компанія "наша". Лист прийшов англійською. З коротким описом фіч до чогось.
Я все розумію - тз мабуть англомовне, та і взагалі рівень інгліша має бути завжди - ну але ж це робота на тиждень! Чому не можна бути попрощє? Не присилати опис абстрактних фіч, а попросити технаря сформулювати нормальний простий неконкретний опис того, що потрібно зробити? І писати не формальною мовою інглішем, а нормально, від себе: "нам потрібно зробити таку-то роботу з такою-то специфікою, віддалено, приблизний термін - ..."?

Взагалі, при повній заповненості мого лінкедіна, дуже дивують різні питання ейчарів, доходило до маразмів - коли мене, на приклад, рекрутили з фірми, на якій я пропрацювала більше 3 років (найшла мене HR через лінкедін, в якому її фірма з терміном, скільки я там пропрацювала, була вказана). Ще дивує повна відсутність внутрішнього обміну інформації про працівника на фірмах (абсолютно всіх!): завести просту базу на всіх абсолютно працівників - потенційних, теперішніх, минулих, з простими зв'язками багато-до-багатьох (з ким коли контактував з простим коментарем: працював в одному тімі, був піемом, дав контакт, був підлеглим, вчились разом, працювали разом, етц, етц, етц) - ну точно не складно для ІТ кантори, тим більше що готові рішення, мабуть вже давно є. Бояться, що таку базу легко буде злити? А що казати про повну передачу всієї інформації, отриманої при комунікаціях - першій, попередній, всіх інтерв'ю - всім решта інтерв'юючим - її нема ніколи, на абсолютно всіх моїх співбесідах.

Ще одна тема, яка вже давно, мабуть, є холіваром - це те, що роботодавці самі накручують зарплати ІТ-шникам, шукаючи спеціалістів тільки сеніор рівня, на проект, який от щойно прийшов і вже і тут починається. Деякі умудряються потім копнути цих спеціалістів, якщо проект закінчився, і потім знову панічно шукають нового... А потім жаліються, які програмісти офігівші: рівня нема, спеціалістів мало, грошей хочуть багато, та ще й тікають, сволочі, коли їм пропонують в півтора рази більшу зарплату - ну а як може бути інакше, скажіть мені, з таким підходом? І не потрібно розказувати про те, як тяжко і затратно вести бізнес в Україні. В цій країні люди умудряються виробництво запускати, і мати з нього якийсь прибуток - ось що дійсно тяжко! А набирати толкових джуніорів і вирощувати їх до мідлів - не дорого і не важко, навіть для маленьких ІТ фірм! Да, пробувати запускати свої дрібні проекти для людей, поки-що не задіяних в комерційних проектах, щоб підвищувати кваліфікацію працівників і напрацьовувати зіграну команду (яку потім тутже кинути на замовника) - це складно, тут потрібно відсіяти якісь технології і підсилювати кілька своїх, закладати немалий баланс. Але всерівно незрівнянно легше, ніж запустити своє виробництво одягу, чи, не приведи б-же, харчів.
Наша країна не дає розростись ІТ до рівня 500-1000 працівників (в одному офісі) - це вже інше питання, і то, все-таки, це частково питання вміння делегувати свої управлінські обов'язки. Але до рівня 100-300 - спокійно (тобто ніхто не заважає, що ще не означає, що це зробити легко). Так що нема чого жалітись, часто ще й маючи за плечима важкі іноземні інвестиції, працюючи з зарубіжними замовниками (які не кидають на половину суми і не просять безплатно переробити все заново), не маючи безпосередньої роботи з клієнтами, товарами, продукцією (що накладає на бізнес мінімальний прохід контролюючих органів), маючи мінімальний ризик бути вибитим з виробництва (мінімальні бекапи всіх основних серверів, швидко знайти на короткий час приміщення з електрикою і нетом - і за 2-3 дні робота повністю відновиться).
А то зараз тільки і чути ниття і одних і других, як все погано, і холівари на тему, загинається чи ні аутсорс. Його спершу організувати правильно треба пробувати, пробувати пробивати нормального рівня освіти і взагалі відстоювати свої і інших права - за свої ж податки, блін, вчитись вести великий бізнес а не тільки вимагати підвищення кваліфікації своїх працівників, організовувати процес розробки - а не просто кидати найдених програмістів на замовника, і т.д. і т.п.

Багато кантор запускають свої тренінг-центри, деякі, при тому, щей умудрились зробити з цього бізнес - значить це можливо, це окупляється.
Проводьте якісь прості конференції зі серйозними доповідачами на актуальні теми по технологіях, на які вам треба постійно закривати вакансії - і якісний приток кандидатів високого рівня вам гарантований! І це реально просто і відносно дешево - не треба виписувати зі Sun-а чи Adobe-а крутих євангелістів, чи шукати Scrum сертифікованих гуру за шалені гонорари. В Україні вже достатньо багато професійних ІТ ком'юніті - людей, які на голому ентузіазмі збирають навколо себе професіоналів їх галузі і обмінюються досвідом. Найдіть час і кошти для своїх досвідчених працівників, щоб вони виступали з доповідями, спонсоруйте зустрічі - і все, це не тренінг-центр організувати.
Зараз дуже бракує тусовок тім-лідів і технічних менеджерів - різні тренінги по організації процесу розропки, архітектурі, плануванні дуже дорогі. А потрібно ж небагато - не крутих дорогих доповідачів зі степенями і сертифікатами, а просто тусовку, в якій ліди і піеми могли б збиратись і обмінюватись власним досвідом.

А ганятись за працівниками, які знають якусь дуже конкретну технологію, щей зі строгим набором конкретних фреймворків, часто при тому щей не перевіряючи яким спеціалістом він взагалі є, який його справжній рівень інших (заявлених ним) технологій, як взагалі працюють його мозги, чи здатен він взагалі написати складний алгоритм, і, саме головне - на скільки він комунікабельний і відкитий до нової інформації, як реагує на постійно змінювані обставини - так це ж взагалі самогубство, народ! Найдіть одного-два гуру потрібного фреймворку, а решту просто толкових спеціалістів потрібної технології - вони підтягнуться за пару тижнів-місяців. І думайте весь час про можливість перекинути працівника на іншу технологію/проект, якщо йому це цікаво і якщо це бідьш-менш адекватно по затратах.

Отака в мене вийшла розкидана простиня про роботодавців, HR і навіть політику, звиняйте )))
Наступний пост, сподіваюсь скоро, напишу про київський FlashGamm 2010.

вівторок, 23 листопада 2010 р.

Як правильно писати код

От так глобально, да )))

Скільки про це вже писано-переписано, і толку. Одні кажуть "оптимізуй!" "коментуй!" "рефакторинг!" "ооп!" "інжекція!" "не дублюй", інші - не оптимізуй, не коментуй і так далі - і будь тут мудрий. От а я спробую ))) - бути мудрою )))

Головне в цьому ділі, взагалі-то, пам'ятати: цвяхи треба забивати молотком, ями копати - лопатами, а сокирою рубати дрова.

Давним-давно інтернети були повільні, процесори слабенькі, пам'ять маленька, вінти тісненькі, кожен байт графіки важив як золото, кожен процес треба було оптимізувати - видумуючи як можна хитріші алгоритми і спрощення. Навіть розмір імені змінної в деяких випадках потрібно було враховувати. Малювання кодом, оптимізаційні фішки - це все було актуальним. БУЛО. Ні, ну зараз теж є задачі, в яких потрібно мінімізувати розмір, об'єм, швидкість сортування масива, кількість запитів до сервера... Але раніше це потрібно було робити незалежно від постановки задачі, комп'ютери/інтернети у всіх були однакові. Але ж зараз ситуація змінилась! Самий простенький домашній канал дає можливість дивитись серіали онлайн, паралельно чатитись у всяких аськах/гтоках, перевіряти пошту і коментувати блоги, яка кому різниця, чи буде ваш клієнт важити на 400 кілобайт більше?
Зараз куди не сунься - важливою стала підтримуваність коду, його повторне використання, легка розширюваність, а значить - читабельність, простота і продуманість. Навіть коли тобі потрібно писати маленькі іграшки, або ж і взагалі якісь не подібні один на інший дрібні проекти - там все одно будуть спільні речі, які не потрібно кожен раз робити заново (якщо взагалі потрібно видумувати велосипед) - люба аплікація має дизайн і взаємодію з користувачем, з'єднання зі сервером. Чому тоді не написати один раз якийсь свій фреймворк, в якому чітко розділений дизайн і код, код при тому мінімально зав'язаний на тому, що саме малює дизайнер, наплодити свою бібліотеку стандартних контролів (при чому не обов'язково там зразу писати всі можливі елементи, зі всіма можливими варіаціями) або освоїти вже існуючу, в якій народ вже за роки назбирав всі можливі граблі під різними осями і девайсами. Чому не писати код акуратно, іменувати змінні по-людськи, щоб особливо і коментувати не прийшлось? Ти ж сам вже за місяць уявлення найменшого не будеш мати, що ти там і для чого написав. Не використовуй колбеків, функцій у функціях - заплутаєшся, не дублюй код - замахаєшся його всюди фіксити, розділяй дані, логіку і візуалізацію, не пиши основний функціонал в хендлерах і конструкторах - з ймовірністю 80% цей код потрібно буде викликати ще раз... І так далі і тому подібне. Люди роками писали тонни коду, написали не одну пачку рекомендацій, б'ються над методиками, описують свої граблі - не треба думати, що ти будеш розумніший за всіх них і тобі це не потрібно.

Починати треба зі занудного - код конвеншин. Взяти за основу якийсь стандарт, підкоригувати під себе, банально завести доку і шаблони - класів, подій. Поступово розширювати його правилами.
Про код конвеншин я, мабуть, напишу окремо - і для чого воно і які мої правила напрацювались довгими роками боротьби з граблями ))

Зіткнувся з якоюсь проблемою - гуглани, вже давно існує купа готових ліб для роботи з коліщатком мишки під маками, міні- і повноцінні 3D, криптування даних, обхід адобівських багів, робота зі шрифтами...
При тому, звісно ж, треба розібратись що воно там, як і для чого - але не потрібно тратити час на винайдення велосипеду зараз і його постійний ремонт потім - google oriented programming рулить )))

Читай методи оптимізації, але пам'яй, що одна ініціалізація масива, яка виконається один раз за всю аплікацію, погоди цій аплікації не зробить, а прогон циклу, який викликається всю дорогу, і в який впихнули оголошення тимчасових змінних - ось те місце, яке треба зразу написати чисто. Не фанатично оптимізувати, а просто чисто написати. Не викликати кожен раз один і той самий запит, який протягом всього виконання аплікації нічого нового не викличе, але і не грузити всю аплікацію кешуваннями даних, які всеодно постійно міняються і їх постійно запитують з параметром reload=true. І взагалі просаджує проц складна прозора графіка і меморіліки, в більшості звичайних аплікух всі інші дрібні оптимізації мало на що вплинуть.

Словом, це все можна послухати-подивитись тут, а я ще хіба опишу один з прикладів як писати потрібно, а як - ні.

От є така проста функція:

static public function zerofy(v: int, u: int = 10): String {
  return String(Math.pow(10, String(u).length - String(v).length)).slice(1) + String(
}


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

Вот скажіть мені, для чого так взагалі писати? Чому не написати просто, хоч і не так вичурно:


static public function zerofy(num: int, lenMarker: int = 10): String {
  var result: String = String(num);
  var len: int = String(lenMarker).length;

  while(result.length < len) {
    result = "0" + result;
  }

  return result;
}


Плоско, тупо, зато акуратно, ясно що робить і як, і без непередбачуваних багів.

пʼятниця, 29 жовтня 2010 р.

Як правильно писати своє резюме!

Поставте себе на місце людини, яка шукає нового працівника. Ні, не так. Уявіть: ви працюєте, над проектом, іноді овертаймаєте, іноді фіксаєте баги, часу не вистачає - ну все як завжди. І тут вам кажуть "проведи співбесіду, ось резюме".
А от тепер подумайте, що ви хотіли б побачити в цьому резюме, щоб воно дало вам максимум інформації і при цьому забрало мінімум часу! І не присилайте, блін, суцільну простиню зі сухим переліком місць навчання і праці. Баба Зіна теж працює на великій софтверній фірмі, а часом і не одній - прибиральницею. І при цьому щей вповні могла закінчила не один вуз. З червоним дипломом. З відзнакою.

Будь-кому, хто оцінює ваші робочі можливості, потрібно побачити ваш код і подивитись, що ви РЕАЛЬНО РОБИЛИ.
Вишліть разом з резюме хоч один маленький проект З КОДОМ! Ви точно десь колись для когось робили тестові завдання чи внутрішні проектики на випробувальному терміні, тим більше, якщо ви працюєте з Флешем!

Опишіть в резюме в хронологічному порядку всі свої проекти, згруповані по місцях роботи. Опишіть в проекті технології, які на ньому використовувались (всі, не тільки ті, якими ви працювали), кількість людей, час скільки ви над проектом працювали, і головне, детально - свої обов'язки і досягнення на цьому проекті.

Коротко: досвід важливіший за освіту, його ставимо вище, спочатку стислий перелік знань, тоді - детальний опис проектів. КОМЕРЦІЙНИЙ ДОСВІД, все некомерційне пишем в районі освіти (або в ній же). ВУЗи мало хто знає, опишіть чого для реальної роботи ви таки навчились там, щоб було ясно, чи ви зовсім самоучка, чи мінімальне ООП і розуміння баз даних чи клієнт-сервера вам дали у ВУЗі.
В описі проекту країна замовника важлива, наявність на проекті ПМ-а (ProjectManager) - важлива, кількість людей - важлива! Крім просто опису проекту - роль в тімі, досягнення, нові знання, архітектурні рішення.


Ось вам приблизний шаблон резюме:

Name

Birth date: xx/xx/xxxx

Address xxxxx, Yyyy str., Lviv, Ukraine

Current address: Zzzzz Ave., Kiev, Ukraine

cell phone: +38 0xx xxx xx xx

mail, GTalk: aaaaaaa@gmail.com

ICQ: xxxxxxxxx

Skype aaa

LinkedIn: url

Keywords

Adobe Flash, ActionScript, Game development, Python/Cheetah, J2ME


Business area

Outsource, Software, RIA, web, RPG, mobile games, casual games, E-Commerce


Experience summary

· 8 years of commercial programming experience

· Extensive knowledge of Adobe Flash technology


Skills

Programming language/Technologies

· Flash (ActionScript 1.0, 2.0, 3.0) (5.5 years)

· Flex (1 year)

· Java/J2ME(mobile phone games)/JSP (1.5 years)

· HTML, JavaScript, XML (5 years)

· PHP/MySQL (2.5 years)

Development tools

· Macromedia/Adobe Flash (v 5 – CS3)

· FlashDevelop+FlexSDK, FlaxBuilder/FlashBuilder, IDEA+FlexSDK, Eclipse+MTASC

· Borland C++ Builder

· Microsoft Visual Studio

Source control software

· SVN

· CVS

· Microsoft SourceSafe

Databases

· MySQL

Operating Systems

· Microsoft Windows 95/98/2000/XP

· FreeBSD

Other

· Papervision3D


Work experience

Period:

Nov 2008

till now

Company name and location: AAA, Kiev

Job position: Senior Flash developer/team lead.

Project: BBB

Customer: USA

Project Description: http://BBB.com

AS3 FlexSDK 3.3, AMF, PHP (Zend)/MySQL

Online RPG brauser game.

Duties and Achievements:

· Team leader

· Communication with client

· General flash project architecture

· Development of components

· Code refactoring, optimization, architecture changes

· Jabber chat client (xiff), Twitter authorization, 3D effects

Team Size: 2 flash developers, 1 PHP/MySQL developer (Kiev team), ½ QA, 1 admin (Russia team), 1 flash developer, 1 server/DB developer, 1 QA (USA team).

Environment and Tools: Adobe Flash CS3, FlashDevelop+FlexSDK, SVN

Project: Mosaic (1 week)

Customer: Greek

Project Description: Small entertaining flash site.

User uploads their picture with info and sees mosaic, based on customer`s given picture from all uploaded pictures. Admin can view and manage all uploaded pictures

Duties and Achievements:

· User part (picture/info upload form, generating mosaic from server-given list and pictures, picture small random preview and full view)

· General flash part architecture

Team Size: PM, 1 flash developers, 1 server/DB developer, 1 artist

Environment and Tools: Adobe Flash CS3, FlashDevelop+FlexSDK, SVN


Period:

May 2007

Nov 2008

Company name and location TTTT, Lviv

Job position: Flash game developer

Project: Casual Flash games (2 month)

Customer: Polish

Project Description:

Small casual games

Duties and Achievements:

· Development of games

· Team leader

· Learned AS3, MVC pattern

· Created project architecture for separating graphics and developing process (AS2, AS3 developing tools)

Team Size: 1 developer, 1 artist

Environment and Tools: Adobe Flash 8, CS3, Eclipse+MTASC, FlashDevelop+FlexSDK

Project: Internal reporting system (1 year)

Customer: Internal, Ukraine

Project Description:

PHP/MySQL internal portal

· employees managing and complicated right levels

· employees reporting by project

· projects managing

· bug tracking system

· complicated reports for different level managers

Duties and Achievements:

· general PHP code optimization

· reports development

· universal module for any item modifying history

· bug fixing

Team Size: PM, 3 server developers, 2 Qas

Environment and Tools: Zend Studio, PHPMyAdmin, Apache, CVS


Period:

Jan 2002

Jan 2004

Different freelance projects, demo, effects, non-commercial projects, practical work:

· C++ Builder,

· Java, J2ME,

· PHP/MySQL,

· C++ (for Linux, Symbian), HTML/JS, Flash.


Education

Period:

1999 – 2004

Lviv Ivan Franko National University, department of Applied Mathematics and Informatics, specialty: Informatics, specialist`s degree.

Learned: C++ (4 years), math base for computer graphics (and 3d), HTML/JS, C++ Builder, SQL, Interbase/FireBird, FoxPro, Java 3D, ESRI Map Object, ESRI ArcView.v31

Master's thesis: 3-D visualization of results of mathematic calculations on server-side


Personal data

· Marital status, children: no

· Driving license: no

· Hobbies: Horse riding, snooker, hiking, dog, swimming

· Other: UAFPUG (http://fpug.org.ua/, ) member, speaker.


Certificates

No


Languages

· English – intermediate low

· Spanish – intermediate high

· Ukrainian – native

· Russian – fluent




Це шаблон з мого резюме. На моїх співбесідах переважно не задавали глупих питань типу "а що таке ООП" чи "як у Флеші аплоадати на сервер файл" - питають по проектах, щоб перевірити правдивість написаного і уточнити реальний об'єм роботи і якість отриманих навиків.
Коли в тебе чітко описано, що ти робив (навіть якщо це щось реально бігаючим не можна побачити в мережі), бачили твій код - то ясно, що ти вже ну точно знаєш, як працювати з класами, фільтрами, ефектами, інтерфейсами, серіалізацією, парсерами...

Коротше кажучи - напишіть один раз нормальне резюме! Ззекономите так і собі і людині, яка має проводити вам співбесіду, час і іноді навіть нерви.

середа, 27 жовтня 2010 р.

використовуйте Error, throw, catch,

ось тут я провтикала і все неправильно нарадила (хоча для дійсно лінивих ;) той варіант буде найкращим).

робити потрібно так (чекаю помідорів від unlarik):


var error: Error = new Error("This call is invalid");
trace(error.getStackTrace());


так взагалі треба писати свою систему виводу дебаг-інформації.

а зовсім правильно описані в тому пості ситуації писати так:


...
throw new Error("This call is invalid");
...

...

try{
...
} catch(error: Error) {
trace(error);
trace(error.getStackTrace());
}

репост з буза: питання про замовників

а скажіть-но дружочки-програмісти і їх манагери: це у всіх нідерландців така фішка працювати без піемів, тестерів та інших організаційних ієрархій, організовуючи лінійний дозований по часу конвеєр? чи то в мене такий досвід попався кривий кілька раз підряд на таку цікаву комбінацію?
бо з американами я такого собі навіть не уявляю (йдеться про замовників більш-менш великих проектів)

і ще цікава тенденція європейців: постановка пошуку працівників типу "шукаєм <якась недитяча технологія> + <якась інша недитяча технологія, не суміжна з першою дитячою технологією>", при цьому взагалі не дають опису реквайрементів, проекту і т.п. - це вони, я так розумію, з індуськими фрілансерами звикли працювати? - типу кидають об'яву, на неї злітається з двадцяток піаністів, з яких 10 знають як правильно пишуться назви недитячих технологій, з них знаходиться два, які піанінять щось більш-менш працююче і з ними якось працюють?

пʼятниця, 15 жовтня 2010 р.

Підказка для лінивих:

Ситуація: у вас баг. Трейс, дебаг, відтворення... результат - якась функція викликається 2 рази підряд. Або більше, ніж має, або в тих умовах, в яких вона не повинна викликатись (до ініціалізації). І все дуже складно - дуже багато різних подій, потенційних місць виклику функції і просто лінь )))) - що неможливо визначити зразу звідки йде косячний виклик. Зато умову, коли виклик функції відбувається неправильно, перевірити можна майже завжди, ну хоча б тупо поставивши лічильник. От в цю умову і пихаєм такий простий код:

var spr: Sprite;
spr.alpha = 1;

Що станеться при виконанні цього коду? - помилка. А що відобразиться у вікні флешплеєра про цю помилку? - правильно: те, що нам потрібно - повний шлях виклику нашої нещасної функції.

середа, 6 жовтня 2010 р.

Порада для проектів зі складною системою подій.

У великих проектах переважно є своя складна система подій (з власними подіями) - вони генеруються користувачем, відповідями зі сервера, по таймеру, автоматично, сукупністю інших подій і т.п.
Вже не перший раз в моєму теперішньому проекті зіткнулась з тим, що в цих подіях мені було б добре знати, чи подія згенерована користувачем.

Найпростіший приклад - користувач може відкрити сторінку повідомлень і звітів, і тоді система посилає запит на сервер за цими самими повідомленнями і звітами. Але ще в системі є панелька, яка підсвічує користувачу, чи прийшли йому нові повідомлення/звіти. Для цього панелька теж генерує такий самий запит, по таймеру (кожну хвилину, на приклад). І ще в системі можливі події, які будуть призводити до оновлення даних зі сервера по звітах і повідомленнях. А от серверу ще потрібно знати час неактивності користувача, і якщо цей час більше години - вилоговувати його. Для цього серверу потрібно розрізняти, де запити, які означають активність користувача, а де - автооновлення.

Ще приклад - є функція показу початкового стану з відображенням панелі управління, яку потрібно викликати і коли всі вікна закриті і коли користувач натиснув кнопку повернення до початкового стану. Коли це все писалось, ніхто не думав про те, що повернення до початкового стану з відображенням панелі і закриття всіх вікон треба розділити, їх зв'язали намертво і зав'язали на одну подію, і про ситуацію, коли користувач відкрив кілька вікон одночасно - теж ніхто не думав.

Прикладів може бути багато - і їх всі можна було б обійти, розділивши функції, зробивши окремі запити, правильно зі самого початку організувавши архітектуру всього проекту. Але, по-перше, зовсім правильно організувати архітектуру великого проекту, на якому щей спостерігається текучка девів, відсутність піема і ТЗ кардинально міняється на льоту (у флеші таке часто трапляється) - нереально. Тим більше, якщо приходиш в середину проекту. Переписати все нафіг - бажання логічне, але на це вже нема часу, і знову-таки: не факт, що ти сам це все перепишеш правильно (див попередній пост).

А от навіть якщо прийшов у проект зі середини, вписати у всю систему подій один маленький прапорець - поки коли дедлайни не тиснуть на горло - не так складно, їсти не просить, а допомогти потім може в дуже багатьох ситуаціях.

понеділок, 4 жовтня 2010 р.

Оголошуєм два класи в одному файлі

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

package {
  
   public class SomeClass {
     
     public function SomeClass() {
       
    }
    
  }
}

  class HelperClass {
    
  }


До речі, раджу завжди в файлі ставити завершуючий EOF (в більшості IDE це можна налаштувати автоматом, в FlashDevelop - Tools-Program Settings-FlashDevelop-Formatting-Ensure Last Line End, і там же є ще одна опція, яку раджу включати - FlashDevelop-Tools-Program Settings-FlashDevelop-Formatting-Strip Ending Spaces).

Здавалось би, прості банальні істини, які всі мали б знати

Влияние качества кода на бизнес

Використовуємо таймери для вирішення різних проблем

От є, здавалось би, проста ситуація (JS-ники її добре знають): користувач наводить мишку на елемент А, з'являється елемент Б, користувач може вибрати один з піделементів Б або забрати мишку з А чи Б, передумавши, і Б має зникнути (приклад - випадаюче, контекстне менюменю). Все просто: навішуємо на стейдж маус лісенер і перевіряємо, чи перетинається з А або Б. Ні - ховаєм Б (чому не навішувати на Б лісенер MOUSE_OUT ви самі дідете методом проб і помилок - якщо досі не дійшли).
А якщо А і Б - зовсім окремі об'єкти, які один про одного не мають нічого знати, і А з Б не перетинаються, тому, при переведенні мишки з А на Б, Б закриється? Ну знову все просто: при створенні об'єкта Б не ініціалізуєм лісенер мишки стейджем доти, поки мишка на нього не зайшла. Але тоді відведення мишки з А його не закриє, поки користувач не наведе мишку на Б - це не зручно. Тоді можна в Б встановлювати прапорець, щось типу _canBeClosed=false, при наведенні мишки на Б піднімати його, у лісенері стейджа перевіряти цей прапорець, і додатково в Б, при появі на екрані, запустити таймер (в середньому на 1.5-2 секунди), на його TIMER_COMPLETE теж піднімати цей прапорець.

До речі, всі "випадіючі" елементи додавайте в стейдж - щоб вони завжди перекривали всі інші візуальні елементи і вам не треба було думати, в якій послідовності які елементи були додані на екран і хто кого перекриє. Ну хто вже зовсім не знає - для їх позиціонування використовуйте localToGlobal().

Ще ситуація: є "важка" функція (запит до сервера за тими самими даними), яка має викликатись тільки один раз в один момент часу. А може вона спрацювати на якийсь лісенер, а в проекті івентами плюються всі кому не лінь і розгрібати цю систему нема можливості, або з якихось причин відрубувати користувачу можливість генерувати івенти, які запускають цю функцію - нема. Словом, є у вас ризик подвійного виклику (і бардаку в наслідок цього) і відловити його причину дуже важко (хоч це і потрібно обов'язково зробити), а проблему вирішити треба, і то дуже швидко. Знову-таки, оголошуєься в тому ж класі статичний прапорець, по замовчуванні false, у виклику функції він перевіряється, якщо false - функція виконується, прапорець піднімається і запускається таймер на потрібний для ігнорування всіх наступних викликів цієї функції час, на його TIMER_COMPLETE прапорець знову встановлюється в false.

Ну і, хто ще раптом не знає, як перевіряти швидкість виконання операцій:

var startDate: Date;
var test1Date: Date;
var test2Date: Date;
var str: String;

startDate = new Date();
for(var i: int = 0; i < 100000; i++) {
  str = _function1(args);
}
test1Date = new Date();

for(var j: int = 0; j < 100000; j++) {
  str = _function2(args);
}
test2Date = new Date();

trace(test1Date.time - startDate.time, test2Date.time - test1Date.time);

Тільки не використовуйте в середині циклів trace - його обробка всіми плагінами, які його ловлять, може давати похибку.