От так глобально, да )))
Скільки про це вже писано-переписано, і толку. Одні кажуть "оптимізуй!" "коментуй!" "рефакторинг!" "ооп!" "інжекція!" "не дублюй", інші - не оптимізуй, не коментуй і так далі - і будь тут мудрий. От а я спробую ))) - бути мудрою )))
Головне в цьому ділі, взагалі-то, пам'ятати: цвяхи треба забивати молотком, ями копати - лопатами, а сокирою рубати дрова.
Давним-давно інтернети були повільні, процесори слабенькі, пам'ять маленька, вінти тісненькі, кожен байт графіки важив як золото, кожен процес треба було оптимізувати - видумуючи як можна хитріші алгоритми і спрощення. Навіть розмір імені змінної в деяких випадках потрібно було враховувати. Малювання кодом, оптимізаційні фішки - це все було актуальним. БУЛО. Ні, ну зараз теж є задачі, в яких потрібно мінімізувати розмір, об'єм, швидкість сортування масива, кількість запитів до сервера... Але раніше це потрібно було робити незалежно від постановки задачі, комп'ютери/інтернети у всіх були однакові. Але ж зараз ситуація змінилась! Самий простенький домашній канал дає можливість дивитись серіали онлайн, паралельно чатитись у всяких аськах/гтоках, перевіряти пошту і коментувати блоги, яка кому різниця, чи буде ваш клієнт важити на 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;
}
Плоско, тупо, зато акуратно, ясно що робить і як, і без непередбачуваних багів.
вівторок, 23 листопада 2010 р.
пʼятниця, 29 жовтня 2010 р.
Як правильно писати своє резюме!
Поставте себе на місце людини, яка шукає нового працівника. Ні, не так. Уявіть: ви працюєте, над проектом, іноді овертаймаєте, іноді фіксаєте баги, часу не вистачає - ну все як завжди. І тут вам кажуть "проведи співбесіду, ось резюме".
А от тепер подумайте, що ви хотіли б побачити в цьому резюме, щоб воно дало вам максимум інформації і при цьому забрало мінімум часу! І не присилайте, блін, суцільну простиню зі сухим переліком місць навчання і праці. Баба Зіна теж працює на великій софтверній фірмі, а часом і не одній - прибиральницею. І при цьому щей вповні могла закінчила не один вуз. З червоним дипломом. З відзнакою.
Будь-кому, хто оцінює ваші робочі можливості, потрібно побачити ваш код і подивитись, що ви РЕАЛЬНО РОБИЛИ.
Вишліть разом з резюме хоч один маленький проект З КОДОМ! Ви точно десь колись для когось робили тестові завдання чи внутрішні проектики на випробувальному терміні, тим більше, якщо ви працюєте з Флешем!
Опишіть в резюме в хронологічному порядку всі свої проекти, згруповані по місцях роботи. Опишіть в проекті технології, які на ньому використовувались (всі, не тільки ті, якими ви працювали), кількість людей, час скільки ви над проектом працювали, і головне, детально - свої обов'язки і досягнення на цьому проекті.
Коротко: досвід важливіший за освіту, його ставимо вище, спочатку стислий перелік знань, тоді - детальний опис проектів. КОМЕРЦІЙНИЙ ДОСВІД, все некомерційне пишем в районі освіти (або в ній же). ВУЗи мало хто знає, опишіть чого для реальної роботи ви таки навчились там, щоб було ясно, чи ви зовсім самоучка, чи мінімальне ООП і розуміння баз даних чи клієнт-сервера вам дали у ВУЗі.
В описі проекту країна замовника важлива, наявність на проекті ПМ-а (ProjectManager) - важлива, кількість людей - важлива! Крім просто опису проекту - роль в тімі, досягнення, нові знання, архітектурні рішення.
Ось вам приблизний шаблон резюме:
Це шаблон з мого резюме. На моїх співбесідах переважно не задавали глупих питань типу "а що таке ООП" чи "як у Флеші аплоадати на сервер файл" - питають по проектах, щоб перевірити правдивість написаного і уточнити реальний об'єм роботи і якість отриманих навиків.
Коли в тебе чітко описано, що ти робив (навіть якщо це щось реально бігаючим не можна побачити в мережі), бачили твій код - то ясно, що ти вже ну точно знаєш, як працювати з класами, фільтрами, ефектами, інтерфейсами, серіалізацією, парсерами...
Коротше кажучи - напишіть один раз нормальне резюме! Ззекономите так і собі і людині, яка має проводити вам співбесіду, час і іноді навіть нерви.
А от тепер подумайте, що ви хотіли б побачити в цьому резюме, щоб воно дало вам максимум інформації і при цьому забрало мінімум часу! І не присилайте, блін, суцільну простиню зі сухим переліком місць навчання і праці. Баба Зіна теж працює на великій софтверній фірмі, а часом і не одній - прибиральницею. І при цьому щей вповні могла закінчила не один вуз. З червоним дипломом. З відзнакою.
Будь-кому, хто оцінює ваші робочі можливості, потрібно побачити ваш код і подивитись, що ви РЕАЛЬНО РОБИЛИ.
Вишліть разом з резюме хоч один маленький проект З КОДОМ! Ви точно десь колись для когось робили тестові завдання чи внутрішні проектики на випробувальному терміні, тим більше, якщо ви працюєте з Флешем!
Опишіть в резюме в хронологічному порядку всі свої проекти, згруповані по місцях роботи. Опишіть в проекті технології, які на ньому використовувались (всі, не тільки ті, якими ви працювали), кількість людей, час скільки ви над проектом працювали, і головне, детально - свої обов'язки і досягнення на цьому проекті.
Коротко: досвід важливіший за освіту, його ставимо вище, спочатку стислий перелік знань, тоді - детальний опис проектів. КОМЕРЦІЙНИЙ ДОСВІД, все некомерційне пишем в районі освіти (або в ній же). ВУЗи мало хто знає, опишіть чого для реальної роботи ви таки навчились там, щоб було ясно, чи ви зовсім самоучка, чи мінімальне ООП і розуміння баз даних чи клієнт-сервера вам дали у ВУЗі.
В описі проекту країна замовника важлива, наявність на проекті ПМ-а (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());
}
робити потрібно так (чекаю помідорів від 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 знають як правильно пишуться назви недитячих технологій, з них знаходиться два, які піанінять щось більш-менш працююче і з ними якось працюють?
бо з американами я такого собі навіть не уявляю (йдеться про замовників більш-менш великих проектів)
і ще цікава тенденція європейців: постановка пошуку працівників типу "шукаєм <якась недитяча технологія> + <якась інша недитяча технологія, не суміжна з першою дитячою технологією>", при цьому взагалі не дають опису реквайрементів, проекту і т.п. - це вони, я так розумію, з індуськими фрілансерами звикли працювати? - типу кидають об'яву, на неї злітається з двадцяток піаністів, з яких 10 знають як правильно пишуться назви недитячих технологій, з них знаходиться два, які піанінять щось більш-менш працююче і з ними якось працюють?
пʼятниця, 15 жовтня 2010 р.
Підказка для лінивих:
Ситуація: у вас баг. Трейс, дебаг, відтворення... результат - якась функція викликається 2 рази підряд. Або більше, ніж має, або в тих умовах, в яких вона не повинна викликатись (до ініціалізації). І все дуже складно - дуже багато різних подій, потенційних місць виклику функції і просто лінь )))) - що неможливо визначити зразу звідки йде косячний виклик. Зато умову, коли виклик функції відбувається неправильно, перевірити можна майже завжди, ну хоча б тупо поставивши лічильник. От в цю умову і пихаєм такий простий код:
var spr: Sprite;
spr.alpha = 1;
Що станеться при виконанні цього коду? - помилка. А що відобразиться у вікні флешплеєра про цю помилку? - правильно: те, що нам потрібно - повний шлях виклику нашої нещасної функції.
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).
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 - його обробка всіми плагінами, які його ловлять, може давати похибку.
А якщо А і Б - зовсім окремі об'єкти, які один про одного не мають нічого знати, і А з Б не перетинаються, тому, при переведенні мишки з А на Б, Б закриється? Ну знову все просто: при створенні об'єкта Б не ініціалізуєм лісенер мишки стейджем доти, поки мишка на нього не зайшла. Але тоді відведення мишки з А його не закриє, поки користувач не наведе мишку на Б - це не зручно. Тоді можна в Б встановлювати прапорець, щось типу _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 - його обробка всіми плагінами, які його ловлять, може давати похибку.
четвер, 30 вересня 2010 р.
PerlinNoise + DisplacementMap
Про те, що можна зробити цією комбінацією - можна знайти дуже дагато інформації. А ось ще один варіант:
Клас Fog, основні функції (я ще не знаю, як сюди правильно вставляти код):
private function _doMagic(event: Event): void {
_canva.lock();
_drawBMPD();
_drawLines();
_smooze();
_canva.unlock();
}
private function _drawBMPD(): void {
_val += 0.5;
_pointOffset1.x = _val;
_pointOffset2.x = _val * 0.1;
_deformationMap.perlinNoise(_middleWidth, _middleHeight, 3,
6456, true, true, 2 | 1,
false, [_pointOffset1, _pointOffset2, _pointZero]);
}
private function _drawLines() : void {
varline : Line;
for(var i: int = 0; i < lines.length; i++) {
line = lines[i];
line.draw();
_canva.draw(line);
}
}
private function _smooze() : void {
_canva.applyFilter(_canva, _canva.rect,
_pointZero, new BlurFilter(3, 2, BitmapFilterQuality.MEDIUM));
_canva.applyFilter(_canva, _canva.rect,
_pointZero, new ColorMatrixFilter([ 1, 0, 0, 0, 2,
.004, 1, 0, 0, 1,
.003, 0, 1, 0, .5,
0, 0, 0, 1, 0]));
}
Основна частина функціїї draw класу Line:
for(var w: int = 0; w < _deformationMap.width; w++ ) {
_value = _deformationMap.getPixel(w, _yIndex) * 0.00001;
graphics.lineTo(w * _scaleMapX, _value * _scaleMapY);
}
Клас Fog, основні функції (я ще не знаю, як сюди правильно вставляти код):
private function _doMagic(event: Event): void {
_canva.lock();
_drawBMPD();
_drawLines();
_smooze();
_canva.unlock();
}
private function _drawBMPD(): void {
_val += 0.5;
_pointOffset1.x = _val;
_pointOffset2.x = _val * 0.1;
_deformationMap.perlinNoise(_middleWidth, _middleHeight, 3,
6456, true, true, 2 | 1,
false, [_pointOffset1, _pointOffset2, _pointZero]);
}
private function _drawLines() : void {
varline : Line;
for(var i: int = 0; i < lines.length; i++) {
line = lines[i];
line.draw();
_canva.draw(line);
}
}
private function _smooze() : void {
_canva.applyFilter(_canva, _canva.rect,
_pointZero, new BlurFilter(3, 2, BitmapFilterQuality.MEDIUM));
_canva.applyFilter(_canva, _canva.rect,
_pointZero, new ColorMatrixFilter([ 1, 0, 0, 0, 2,
.004, 1, 0, 0, 1,
.003, 0, 1, 0, .5,
0, 0, 0, 1, 0]));
}
Основна частина функціїї draw класу Line:
for(var w: int = 0; w < _deformationMap.width; w++ ) {
_value = _deformationMap.getPixel(w, _yIndex) * 0.00001;
graphics.lineTo(w * _scaleMapX, _value * _scaleMapY);
}
Лінки
3д-шні сайти, які мені дуже сподобались:
http://ecodazoo.com/
http://www.pluginmedia.net/clients/bigandsmall/phase1c_release/game/
Іграшки, які я дуже люблю:
http://armorgames.com/play/2205/light-bot - перевірте, який з вас програміст ))
http://www.daymaretown.com/ і взагалі http://www.pastelportal.com/stories/the-submachines/
http://www.eyezmaze.com/grow/RPG/index.html - дуже люблю їх grow-си.
Підбірка книжок для управління процесом кодання: http://www.litru.ru/bs/?g=sg46&genre=sg46&order=rating_down&o=10&p=1
Мої дрібні іграшки (з багами, гальмами і глюками, це були тижневі тестові завдання):
AS2: http://www.swfcabin.com/swf-files/1258307871.swf
AS3 (на цій іграшці я його і вивчила): http://www.swfcabin.com/swf-files/1258307871.swf
І, до речі - сайт, де можна викладати свої swf: http://www.swfcabin.com/
http://ecodazoo.com/
http://www.pluginmedia.net/clients/bigandsmall/phase1c_release/game/
Іграшки, які я дуже люблю:
http://armorgames.com/play/2205/light-bot - перевірте, який з вас програміст ))
http://www.daymaretown.com/ і взагалі http://www.pastelportal.com/stories/the-submachines/
http://www.eyezmaze.com/grow/RPG/index.html - дуже люблю їх grow-си.
Підбірка книжок для управління процесом кодання: http://www.litru.ru/bs/?g=sg46&genre=sg46&order=rating_down&o=10&p=1
Мої дрібні іграшки (з багами, гальмами і глюками, це були тижневі тестові завдання):
AS2: http://www.swfcabin.com/swf-files/1258307871.swf
AS3 (на цій іграшці я його і вивчила): http://www.swfcabin.com/swf-files/1258307871.swf
І, до речі - сайт, де можна викладати свої swf: http://www.swfcabin.com/
Про ситуацію з флешем у Львові.
Думки по темі написала, коли приймала рішення переїжджати зі Львова у Київ:
у львові флеша майже нема, ті варіанти які пропонують - не дуже великі гроші, нема відпусток, лікарняних, або вони малі. і за нього взагалі ІТшні кантори львова не беруться, а якщо і беруться - то потім відмовляються: спеціалістів найти важко, та щей окремо толкових дизайнерів-аніматорів треба, проект треба менеджити кучеряво: і як дизайнерський (результат візуальний - кастомер тут же рветься вносити багато змін - якщо менеджмент до цього не звик, будуть проблеми) і як програмістський... словом, середньостатистичній ІТ канторі у львові краще брати джавні/сішні/дотнетівські замовлення, які вони добре знають як вести, і під які вони легко знайдуть працівників, ніж зв'язуватись з такою кучерявою технологією.
мені все-таки хочеться довести свій досвід, який до того був дуже рваний, в одній технології до нормальної серйозної глибини. вже на щось інше перескакувати буде легше, якщо я спершу зарекомендую себе (і принесу канторі бабло) як сеніор. тому все-таки флеш, а не переучуватись.
у львові флеша майже нема, ті варіанти які пропонують - не дуже великі гроші, нема відпусток, лікарняних, або вони малі. і за нього взагалі ІТшні кантори львова не беруться, а якщо і беруться - то потім відмовляються: спеціалістів найти важко, та щей окремо толкових дизайнерів-аніматорів треба, проект треба менеджити кучеряво: і як дизайнерський (результат візуальний - кастомер тут же рветься вносити багато змін - якщо менеджмент до цього не звик, будуть проблеми) і як програмістський... словом, середньостатистичній ІТ канторі у львові краще брати джавні/сішні/дотнетівські замовлення, які вони добре знають як вести, і під які вони легко знайдуть працівників, ніж зв'язуватись з такою кучерявою технологією.
мені все-таки хочеться довести свій досвід, який до того був дуже рваний, в одній технології до нормальної серйозної глибини. вже на щось інше перескакувати буде легше, якщо я спершу зарекомендую себе (і принесу канторі бабло) як сеніор. тому все-таки флеш, а не переучуватись.
Про мінімальні вимоги до ведення проекту
LJ
buzz
3 речі (крім власне програмістів) мають бути на проекті: ПМ (одна, відповідальна за всіх решту на проекті, і ведуча всі комунікації зі замовником, не кодаюча людина), ТЗ (дооооовго і дотооооошно всіма сторонами вичитане, повне і пророблене до найдрібніших детальок - ну це в ідеалі - технічне завдання або просто "що в кінці має вийти"), і повноцінне постійне тестування. якщо їх нема - не жалійтесь, що всьо пльохо і все валиться і все не так. їх наявність - ще не гарантія успіху проекта. їх відсутність - проект буде виконано якимись титанічними зусиллями з перебором всіх термінів і тільки за участі чуда (два штука і третя на підстраховці).
не раджу нікому працювати на таких проектах.
buzz
3 речі (крім власне програмістів) мають бути на проекті: ПМ (одна, відповідальна за всіх решту на проекті, і ведуча всі комунікації зі замовником, не кодаюча людина), ТЗ (дооооовго і дотооооошно всіма сторонами вичитане, повне і пророблене до найдрібніших детальок - ну це в ідеалі - технічне завдання або просто "що в кінці має вийти"), і повноцінне постійне тестування. якщо їх нема - не жалійтесь, що всьо пльохо і все валиться і все не так. їх наявність - ще не гарантія успіху проекта. їх відсутність - проект буде виконано якимись титанічними зусиллями з перебором всіх термінів і тільки за участі чуда (два штука і третя на підстраховці).
не раджу нікому працювати на таких проектах.
Про тестові завдання на співбесідах
buzz
от може я не права, але на даний момент для себе я вирішила: більше ніяких тестових завдань робити не буду.
7 років досвіду в ІТ, що можна побачити ще по якомусь там тестовому завданні? після 7 років людина вже йде на серйозну посаду. тут вже важливим є архітектурне мислення, вміння працювати в команді, знаходити рішення, кодати чіткими структурами, які легко буде потім переробити і підтримувати, легко читати чужий код. це виявиш по якомусь 1-2денному завданні? - та ніфіга! я знаю людей, які зроблять тобі любої складності завдання, а працювати в команді з ними нереально важко - підвищена конфліктність і небажання переробляти роботу на (оплачувану) вимогу замовника, повне невміння розподілити завдання між людьми, передбачити наступні кроки і потребу в використанні вже створених компонент, розхлябаність і т.п. на то є співбесіда і випробувальний термін.
ну 1-годинне завдання "нє атхадя ат каси" на забезпеченому для цього робочому місці зі всім необхідним софтом для виконання завдання - так, добре. а ~4, а то і більше годин марудитись в поза-робочий час, щоб довести, що ти не слон (в резюме досить детально описано всі проекти, які я робила - любий толковий технар може мене по них опитати і визначити, чи я це дійсно робила і який об'єм якого рівня роботи був зроблений) - вибачте, я не джуніор, в мене виснажлива робота і після неї мої мізки відмовляються включатись для додаткового кОхання з компом. та і взагалі того компа в мене може дома і не бути.
тим більше, інколи канторам треба не забувати, хто кому потрібен: якщо людина потрібна тут і вже, і тобі рекрутер якимись бубнами вицапав працевлаштовану і більш-менш задоволену своєю роботою людину потрібної тобі кваліфікації, то це вже ти маєш зацікавити людину перейти до тебе (ясно ж, перевіривши рівень, можна дати паперове завдання на 15 хв, можна посадити покодати на годину - але не більше), а не вимагати витратити свій і так короткий поза-робочий час на додаткове сидіння за компом.
пишу це вже як людина, яка і сама почала проводити співбесіди.
от може я не права, але на даний момент для себе я вирішила: більше ніяких тестових завдань робити не буду.
7 років досвіду в ІТ, що можна побачити ще по якомусь там тестовому завданні? після 7 років людина вже йде на серйозну посаду. тут вже важливим є архітектурне мислення, вміння працювати в команді, знаходити рішення, кодати чіткими структурами, які легко буде потім переробити і підтримувати, легко читати чужий код. це виявиш по якомусь 1-2денному завданні? - та ніфіга! я знаю людей, які зроблять тобі любої складності завдання, а працювати в команді з ними нереально важко - підвищена конфліктність і небажання переробляти роботу на (оплачувану) вимогу замовника, повне невміння розподілити завдання між людьми, передбачити наступні кроки і потребу в використанні вже створених компонент, розхлябаність і т.п. на то є співбесіда і випробувальний термін.
ну 1-годинне завдання "нє атхадя ат каси" на забезпеченому для цього робочому місці зі всім необхідним софтом для виконання завдання - так, добре. а ~4, а то і більше годин марудитись в поза-робочий час, щоб довести, що ти не слон (в резюме досить детально описано всі проекти, які я робила - любий толковий технар може мене по них опитати і визначити, чи я це дійсно робила і який об'єм якого рівня роботи був зроблений) - вибачте, я не джуніор, в мене виснажлива робота і після неї мої мізки відмовляються включатись для додаткового кОхання з компом. та і взагалі того компа в мене може дома і не бути.
тим більше, інколи канторам треба не забувати, хто кому потрібен: якщо людина потрібна тут і вже, і тобі рекрутер якимись бубнами вицапав працевлаштовану і більш-менш задоволену своєю роботою людину потрібної тобі кваліфікації, то це вже ти маєш зацікавити людину перейти до тебе (ясно ж, перевіривши рівень, можна дати паперове завдання на 15 хв, можна посадити покодати на годину - але не більше), а не вимагати витратити свій і так короткий поза-робочий час на додаткове сидіння за компом.
пишу це вже як людина, яка і сама почала проводити співбесіди.
Про ІТ (або Україна - не Індія)
Як і обіцяла, копіюю сюди свої технічні дописи з інших блогів.
Тут і я собі вирішила пофілософствувати про індусів і організаційні моменти ІТ в Україні.
LJ
buzz
колись давно ще, я почула фразу про те, чого замовники, попри більші ціни, йдуть до нас (україну-росію-білорусію), а не до індусів: у нас є менеджери. тобто нам можна дати таск - повноцінний проект чи його частину, і ми тут видамо його рішення, наш аутсорсинг - закрита чорна коробка (яка звісно ж, має свою ціну - за кожну годину кожного учасника цієї коробки, прозвітовану і обгрунтовану), на вході якої - ПМ, на виході - результат. яким би замороченим не був замовник а деви розхлябані - замовника на себе бере ПМ, як і відповідальність за все, що робить кожен учасник його команди. коштує це відповідно. але це дешевше, ніж наймати в себе менеджерів, які будуть віддалено давати пендюлі зааутстафеним індусам-піаністам.
індуси (нє, ну в них там теж є повноцінний добрий аутсорсинг, а в нас - піаністів навіть з піемами, тут я узагальнюю) - сидять собі і беруть дешевизною і кількістю. навіть по тюрмах, якщо вірити новині, яка якось проскакувало в інтернетах. от просто сидять і кодять, досить таки несамостійно (ті, які закінчили якісь 1-2річні курси, а не ті, хто реально чогось досяг - це так, як я це собі уявляю). їх збирають директори в одній фірмі, забезпечують компами, нетом, приміщенням (в якому садять штабелями), елєктрикою, укладають зі замовником контракт, перекладають, якщо треба, проводять весь грошооббіг, контролюють те, що можуть - дисциплінованість і невідривність від робочого місця.
дешево і сердито: ти більш-менш знаєш, що тобі треба, ти знаєш як це має робитись, ти не хочеш платити середні європейські/гамерицькі зарплати і податки з них - ти йдеш до індусів, платиш дешево і отримуєш кількісний прогнозований конвеєрний результат.
а от коли ти хочеш щось (що і не завжди сформулювати можеш), не дуже знаєшся на технічному аспекті виконання завдання - ти йдеш до когось, хто може може зібрати потрібних виконавців - може тих же піаністів, може і ні - організує їх і покерує так, щоб оптимально видати тобі рішення твоєї задачі. може і не завжди оптимально. але якось цілісно і самостійно.
багато хто називає офшор нудною нетворчою роботою, сірою і буденною. може я чогось не розумію, але по-моєму це в корінь не правда: якщо тобі дають кусок чогось, що ти самостійно маєш вирішити, ти по-любому маєш певну свободу рішень і варіантів, які маєш перебрати і добитись ними виконання потрібного продукту.
взагалі за рішенням ідуть до самостійних людей, і людей творчих. ну хоть чучуть.
а самостійність (це вже на замітку директорам) і творчість - вони потребують свободу, а не дисципліну (виконання якої ніколи не забезпечить нормальної творчої роботи), комфорт, зручність і підлаштовуваність, а не конвеєрність. час і ресурси на навчання, самовдосконалення і розвиток. бо платять за дисципліну індусам. до нас ідуть і нам платять не за кількість, а за самостійне повноцінне рішення. місцями десь трошки творче.
от.
------------
і мої ж думки з коментів:
взагалі цей пост про те, що робота простих дисциплінованих девів без манагера напряму з замовником - це більш індустський підхід, їх кількісна модель (а є в них і якісна модель - і їх таких кантор є теж більше, ніж наших - да). і україні ця модель не підходить - бо витрати на одного піаніста тут більші, освіти і податкових бонусів майже нема, кількості нема, і раз він нічим не відрізняється від індуса - то краще піти до дешевшого і доступнішого і дисциплінованішого індуса.
українській компанії, щоб втримати замовника (добре всі наші замовники, про яких я чула, знали де їх продукт кодається і за якими цінами) в себе а не в індію пустити, треба надавати менеджерів, які з цих піаністів вміють зібрати більш-менш працююче рішення.
-------
спеців я часто бачу непоганих (їх мало, але вони є - вони на рівні спілкуються в блогах з зарубіжними мега-гуру, вони видають рішення на недокументовані фічі і описують їх в статтях, вони постять баги в багтрекери великих софтверних фірм). значить якість на якісь цікаві, повноцінні, серйозніші ніж простий аутсорс рішення є. проблема, мені здається, в маркетингу - власне невмінні вивести якусь компанію з рівня 300 (а в нас дуже важко директори переводять фірми з 30 на 50 і 100 - звичайні помилки управління персоналом лізуть тутже жирним комом) до 1000. ну і наша державна ситуація в сфері бізнесу не сприяє цьому аж ніяк. не беруть на себе директори ризик наймати працівників в холосту, давати їм розробляти якийсь серйозний важкий інноваційний внутрішній проект, щоб ті натренувались, зіргались в команді, набрали скілів і заявили про себе голосно, як команда суперкваліфікованих професіоналів. та і свій продукт, в кінці кінців випустили (як альтернатива3д, до речі - окупилось же їм 100крат)! з нашою то базою наукових досліджень обробки інформації і сортувальних алгоритмів!
а ні, наші фірми в кращому випадку дадуть тобі пм-а, тестера, замовника і 10% часу дозволять тратити на навчання - і працюй тихенько. тільки замовник кінчається - до побачення. тільки з'явився новий замовник - АААААААААААА! СРОООООЧНОООООООО! треба спєцаааааа! саме на таку-во-во технологію, вже тут і зараз, сеніора (до речі вже багато кантор зрозуміли, що сеніорів наймати - невдячна справа. треба наростити своїх піемів і набирати джуніорів, яких самим ростити до сеніорів). і це я про "в кращому разі". а є ще гірші.
і от є індія, 50% девів якої - піаністи, які закінчили якісь 1-2-річні (в кращому, мабуть, разі) курси по джаві (а решта ж і сильніші - но наші ж вродь як не гірші - щей враховуючи, що освіту їм ніхто не давав, самі доросли), але яка дає їм податкові поблажки і вони захоплюють ринок дорогих рішень - десь кількісно, десь якісно.
Тут і я собі вирішила пофілософствувати про індусів і організаційні моменти ІТ в Україні.
LJ
buzz
колись давно ще, я почула фразу про те, чого замовники, попри більші ціни, йдуть до нас (україну-росію-білорусію), а не до індусів: у нас є менеджери. тобто нам можна дати таск - повноцінний проект чи його частину, і ми тут видамо його рішення, наш аутсорсинг - закрита чорна коробка (яка звісно ж, має свою ціну - за кожну годину кожного учасника цієї коробки, прозвітовану і обгрунтовану), на вході якої - ПМ, на виході - результат. яким би замороченим не був замовник а деви розхлябані - замовника на себе бере ПМ, як і відповідальність за все, що робить кожен учасник його команди. коштує це відповідно. але це дешевше, ніж наймати в себе менеджерів, які будуть віддалено давати пендюлі зааутстафеним індусам-піаністам.
індуси (нє, ну в них там теж є повноцінний добрий аутсорсинг, а в нас - піаністів навіть з піемами, тут я узагальнюю) - сидять собі і беруть дешевизною і кількістю. навіть по тюрмах, якщо вірити новині, яка якось проскакувало в інтернетах. от просто сидять і кодять, досить таки несамостійно (ті, які закінчили якісь 1-2річні курси, а не ті, хто реально чогось досяг - це так, як я це собі уявляю). їх збирають директори в одній фірмі, забезпечують компами, нетом, приміщенням (в якому садять штабелями), елєктрикою, укладають зі замовником контракт, перекладають, якщо треба, проводять весь грошооббіг, контролюють те, що можуть - дисциплінованість і невідривність від робочого місця.
дешево і сердито: ти більш-менш знаєш, що тобі треба, ти знаєш як це має робитись, ти не хочеш платити середні європейські/гамерицькі зарплати і податки з них - ти йдеш до індусів, платиш дешево і отримуєш кількісний прогнозований конвеєрний результат.
а от коли ти хочеш щось (що і не завжди сформулювати можеш), не дуже знаєшся на технічному аспекті виконання завдання - ти йдеш до когось, хто може може зібрати потрібних виконавців - може тих же піаністів, може і ні - організує їх і покерує так, щоб оптимально видати тобі рішення твоєї задачі. може і не завжди оптимально. але якось цілісно і самостійно.
багато хто називає офшор нудною нетворчою роботою, сірою і буденною. може я чогось не розумію, але по-моєму це в корінь не правда: якщо тобі дають кусок чогось, що ти самостійно маєш вирішити, ти по-любому маєш певну свободу рішень і варіантів, які маєш перебрати і добитись ними виконання потрібного продукту.
взагалі за рішенням ідуть до самостійних людей, і людей творчих. ну хоть чучуть.
а самостійність (це вже на замітку директорам) і творчість - вони потребують свободу, а не дисципліну (виконання якої ніколи не забезпечить нормальної творчої роботи), комфорт, зручність і підлаштовуваність, а не конвеєрність. час і ресурси на навчання, самовдосконалення і розвиток. бо платять за дисципліну індусам. до нас ідуть і нам платять не за кількість, а за самостійне повноцінне рішення. місцями десь трошки творче.
от.
------------
і мої ж думки з коментів:
взагалі цей пост про те, що робота простих дисциплінованих девів без манагера напряму з замовником - це більш індустський підхід, їх кількісна модель (а є в них і якісна модель - і їх таких кантор є теж більше, ніж наших - да). і україні ця модель не підходить - бо витрати на одного піаніста тут більші, освіти і податкових бонусів майже нема, кількості нема, і раз він нічим не відрізняється від індуса - то краще піти до дешевшого і доступнішого і дисциплінованішого індуса.
українській компанії, щоб втримати замовника (добре всі наші замовники, про яких я чула, знали де їх продукт кодається і за якими цінами) в себе а не в індію пустити, треба надавати менеджерів, які з цих піаністів вміють зібрати більш-менш працююче рішення.
-------
спеців я часто бачу непоганих (їх мало, але вони є - вони на рівні спілкуються в блогах з зарубіжними мега-гуру, вони видають рішення на недокументовані фічі і описують їх в статтях, вони постять баги в багтрекери великих софтверних фірм). значить якість на якісь цікаві, повноцінні, серйозніші ніж простий аутсорс рішення є. проблема, мені здається, в маркетингу - власне невмінні вивести якусь компанію з рівня 300 (а в нас дуже важко директори переводять фірми з 30 на 50 і 100 - звичайні помилки управління персоналом лізуть тутже жирним комом) до 1000. ну і наша державна ситуація в сфері бізнесу не сприяє цьому аж ніяк. не беруть на себе директори ризик наймати працівників в холосту, давати їм розробляти якийсь серйозний важкий інноваційний внутрішній проект, щоб ті натренувались, зіргались в команді, набрали скілів і заявили про себе голосно, як команда суперкваліфікованих професіоналів. та і свій продукт, в кінці кінців випустили (як альтернатива3д, до речі - окупилось же їм 100крат)! з нашою то базою наукових досліджень обробки інформації і сортувальних алгоритмів!
а ні, наші фірми в кращому випадку дадуть тобі пм-а, тестера, замовника і 10% часу дозволять тратити на навчання - і працюй тихенько. тільки замовник кінчається - до побачення. тільки з'явився новий замовник - АААААААААААА! СРОООООЧНОООООООО! треба спєцаааааа! саме на таку-во-во технологію, вже тут і зараз, сеніора (до речі вже багато кантор зрозуміли, що сеніорів наймати - невдячна справа. треба наростити своїх піемів і набирати джуніорів, яких самим ростити до сеніорів). і це я про "в кращому разі". а є ще гірші.
і от є індія, 50% девів якої - піаністи, які закінчили якісь 1-2-річні (в кращому, мабуть, разі) курси по джаві (а решта ж і сильніші - но наші ж вродь як не гірші - щей враховуючи, що освіту їм ніхто не давав, самі доросли), але яка дає їм податкові поблажки і вони захоплюють ринок дорогих рішень - десь кількісно, десь якісно.
Підписатися на:
Дописи (Atom)