Кто бросил программирование ?

[zackscript]

http://cs630220.vk.me/v630220723/35385/DHv-Pxv5hxg.jpg
Народ вопрос серьёзный , быть может это поможет и мне в моём саморазвитии.
Так есть такие кто реально бросил это ремесло и занялся своим делом или бизнесом , может и устроились на другую работу или встали на путь творческого или духовного развития ?

[dark256]

В процессе. Но как хобби это не может не остаться.

[caseyryan]

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

[CrazyFlasher]

2caseyryan вот ты последнее время постоянно хвалишь юнити. Выскажу своё мнение по поводу юнити (может не очень подходящий топик выбрал)
1. Я поработал год вплотную с юнити.
2. Сделали небольшой командой это на Unity 4.5:
https://www.youtube.com/watch?v=Gf0zWYzzHcE
3. Понял, какое юнити Г для работы в команде. Очень высокоуровневый. Годится в большей степени для инди девелоперов прототопов, чтобы как можно быстрее получить wow эффект. Конструктор с глючным закрытым фреймворком. Не было (может уже появились) никакой возможности наладть "взрослую" CI.
Хотя по-началу, когда с ним соприкоснулся рассуждал так же как и ты.
4. Вернулся во Flash.

[dark256]

А я нашел халтурку в типографии - этикетки на пачки с чаем клеить. Смена - 100 руб. 8 часов....

[illuzor]

100 руб. 8 часов....Рабство снова законно? О_о

[dark256]

1200 руб :)

[caseyryan]

2caseyryan вот ты последнее время постоянно хвалишь юнити. Выскажу своё мнение по поводу юнити (может не очень подходящий топик выбрал)
1. Я поработал год вплотную с юнити.
2. Сделали небольшой командой это на Unity 4.5:
https://www.youtube.com/watch?v=Gf0zWYzzHcE
3. Понял, какое юнити Г для работы в команде. Очень высокоуровневый. Годится в большей степени для инди девелоперов прототопов, чтобы как можно быстрее получить wow эффект. Конструктор с глючным закрытым фреймворком. Не было (может уже появились) никакой возможности наладть "взрослую" CI.
Хотя по-началу, когда с ним соприкоснулся рассуждал так же как и ты.
4. Вернулся во Flash.
Есть косяки, не спорю. Но я уверен на все 100, что у вашей команды в собственном as3 фреймворке глюков еще больше, и даже близко нет таких возможностей для построения игр. Иначе просто даже не пытались бы перейти на юнити или что-то другое. Свои минусы есть везде, но плюсов у юнити больше, чем минусов. И да, в 5й версии юнити пофиксили очень много багов, которые были в 4й. У меня сейчас стоит версия 5.3.5, пока ни одного серьезного бага не обнаружил. Хотя еще совсем в недавних версиях, был баг с невозможностью выделения отдельного объекта, если их все положить в общий контейнер.
Я точто знаю, что, к примеру GLU, полностью перешли с собственных технологий на Unity еще начиная со второй части контракт киллера. Думаю, что за компания глу, в мире игростроя и так все знают. Такие не принимают необдуманных решений.
Кстати, для чего тебе в этой игре мог бы потребоваться более низкий уровень?

п.с. по поводу CI, сейчас есть Unity Cloud Build

[CrazyFlasher]

Чтобы программировать, а не шлёпать код на объекты :)
Возможно ли в юнити организовать модульный подход к программированию? Unit тесты? Настройка билда под все платформы по нажатию кнопочки?
Что касается кода: например, как с помощью юнити решить достаточно тривиальную задачу: рисовать тректорию полёта бильярдного шара? А именно склонировать физ мир и показывать в нём будущее. Видимо, не написав или не скачав для этого какую-то приблуду с ассер стора - никак. Т.е. юзать нативную физику не получится, т.к. всё очень на высоком уровне. Есть MonoBehaviour компонент - юзайте.
Опять же говорю, всё это ИМХО и с более старыми версиями юнити. Я просто делюсь своими впечатлениями о работе с ним.

[Psycho Tiger]

@TS: возникало, чтобы быть каким-нибудь важным банкиром в белой рубашечке. Потом прошло, когда стало модно быть бомжом (https://en.wikipedia.org/wiki/Digital_nomad). Сейчас уходить из программирования не думаю и получаю огромное удовольствие от того, что всё крутится на кончиках пальцев; однако вероятность того, что писание кода отойдёт на второй план (для меня) велика – но это не значит, что я уйду из IT и это не значит, что я перестану работать с кодом напрямую.

[GBee]

Я подумываю уйти в стройку каркасников. Уж больно они мне нравятся, да и работа на свежем воздухе.

[Max_Payn]

каких каркасников?

[caseyryan]

Unit тесты?
Вижу, что ты написал ИМХО, поэтому тоже скажу свое имхо. Мне вообще юнит тесты никогда не пригождались. Если делить программистов на тех, кто без юнит тестов жить не может, и тех, кому они вообще не нужны, то я второй вариант. Пробовал как-то раньше в джаве делать все "по фен шую" с юнит тестами, и быстро пришел для себя к выводу, что это бессмысленное занятие. Я не утверждаю, что это на 100% так, может быть реально есть ситуации, где они очень даже полезны, но мне за 7 лет ни разу такой ситуации не встречалось.
Настройка билда под все платформы по нажатию кнопочки?
Нет. А где такая кнопочка есть? Во флеше уж точно нет. Но после того, как ты все настроишь первый раз, то последующие сборки - это не проблема (так же как и во флеше, собственно)
например, как с помощью юнити решить достаточно тривиальную задачу: рисовать тректорию полёта бильярдного шара? А именно склонировать физ мир и показывать в нём будущее.
То есть, ты хочешь сказать, что во флеше это делается на раз два?
Задача вполне решаема, и на флеше и на юнити, но и там и там, она потребует определенных усилий.

Ну и, помимо юнити есть еще Unreal Engine, у которого даже исходники открыты. Отличная технология, но тоже не лишенная своих минусов. Поработав и в том и в том, пришел к выводу, что для ПК анрил лучше, а для мобил - юнити. Все это тоже мое ИМХО.

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

[Tails]

Что насчёт разделения вида от модели в юнити? Я на первый взгляд, как понял, там всё действительно очень высокоуровнево, на столько, что вид от модели не отделим.

На хабре видел статью, где чел делил всех людей по использованию ими тестов. Нет тестов - давай до свидания. :)
пс. Всё хорошо в меру.

[caseyryan]

Что насчёт разделения вида от модели в юнити?
как-то так https://www.toptal.com/unity-unity3d/unity-with-mvc-how-to-level-up-your-game-development
На хабре видел статью, где чел делил всех людей по использованию ими тестов. Нет тестов - давай до свидания.
Да, на хабре много всякой хрени пишут.

[CrazyFlasher]

Мне вообще юнит тесты никогда не пригождались.
Я вижу (без обид) отсутсвие опыта в работе больших команд, где существует текучка кадров и код развивается и мутирует в процессе жизненного цикла продукта. В таких ситуация и unit и integration тесты необходимы (само собой без излишеств), иначе код превращается в полное Г (как показывает практика).
Нет. А где такая кнопочка есть? Во флеше уж точно нет.
Можно настроить процесс сборки как угодно. Сборка обычно осуществляется с на билд машине, которая подхватывает сорсы из репозитори. Вот (может не самый удачный) пример:
http://www.tiefenauer.info/ci-for-flex-mobile-applications-part-0-the-setup/
То есть, ты хочешь сказать, что во флеше это делается на раз два?
Задача вполне решаема, и на флеше и на юнити, но и там и там, она потребует определенных усилий.
Например, в Flash используя тот же nape я могу это реализовать и физика будет симулироваться используя одну и ту же библиотеку.
В юнити API встроенной физики мне это не позволяет сделать. Значит мне нужно либо писать свою физику, либо покупать. Но эта физика не будет в любом случае работать 1 в 1 как нативная, и траектория движения шара не будет точной.
И про бильярд это первое, что пришло в голову. А таких вещей во время разработки появляется достаточно. В итоге проще от таких фич отказавться и результат продукта встаёт рядом с остальными наштампованными клонами.

[Tails]

CrazyFlasher,
А можно поинтересоваться, чтоб для сравнения, что это за проект и сколько над ним трудится в один момент времени разработчиков, раз тесты начинают иметь такое жизненно важное значение?

[CrazyFlasher]

Ну к примеру элементарная кастомная библиотека событий. Да те же as3-signals.
Допустим ты решил написать что-то подобное. Выложил в опен сорс. Другие челы стали тоже юзать, твою клёвую либу. Решил апдейтнуть. Как ты можешь гарантировать, что у других ничего не сломается? Как ты вообде будешь осуществлять тетсирование данного модуля? Обкатывать на своём проекте? - тоже выход. Но неудобно.

[Tails]

Хорошо, понятно.
А вот в рамках большого проекта, сколько примерно приходиться делать тестов?

[CrazyFlasher]

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

[Tails]

Ясненько, понятненько.
Ну это точно не для инди проектов.

[caseyryan]

Я вижу (без обид) отсутсвие опыта в работе больших команд
Да на что тут можно обижаться? К сожалению такого опыта нет (а может и ксчастью, хз). У нас команда маленькая.
Но, раз уж разговор пошел о юнит тестах, я просто не мог поверить, что такая известная штука как юнити, страдает их отсутствием. И нагуглил вот это http://blogs.unity3d.com/2014/07/28/unit-testing-at-the-speed-of-light-with-unity-test-tools/
Мне сложно судить на сколько это удобно, так как для меня вообще юнит тесты не удобная штука, но, тем не менее.
В общем, как я понял, у тебя просто предвзятое отношение к юнити из-за каких-то неоправданных ожиданий, возможно. Утверждать, что она подходит для всех игровых проектов - глупо. Конечно же нет. Действительно, есть такие проекты, где проще и лучше запилить что-то свое. Но процентов 85 - 90 она точно может покрыть. И дело ведь не в том, на сколько технически сложнен проект, а в том, какой фан он создает. Часто простые игры затягивают гораздо сильнее, чем навороченные с многомиллионными бюджетами

[Psycho Tiger]

Если делить программистов на тех, кто без юнит тестов жить не может, и тех, кому они вообще не нужны, то я второй вариант.
Это как героин. Стоит один раз увлечься и...
Но вообще говоря, здесь уместней сравнение с ООП при AS2 – сначала непонятно, странно и хочется написать в процедурном стиле (или смешать и то, и то), но после осознания голова не работает иначе. Сейчас перед тем как написать любой код я первым делом думаю, как написать для него разные тесты на разных уровнях. Доходит вплоть до попиксельных сравнений картинок, если манипулирую ими.
Нет. А где такая кнопочка есть?
В контексте сбора приложений, грубо говоря, она должна быть всегда. Внешний консультант при заходе на проект с целью разгрести кучу мусора первым делом будет делать именно то, чтобы проект запустился с одной кнопки, или, максимум, с строго предетерминированным порядком действий (который, кстати, можно запихнуть в скрипт и вот она, одна кнопка!). Общих решений подходящих везде не существует, но для каждого отдельного проекта сборка в одну кнопку просто essential. Сравни какой-нибудь MEAN Stack и Hadoop в простоте сборке. Они вообще для разного, но со вторым можно умом тронутся пока он просто встанет. (на всякий упомяну, что мой скоуп знаний о Hadoop достаточно старый – надеюсь, многое изменилось).

На хабре видел статью, где чел делил всех людей по использованию ими тестов. Нет тестов - давай до свидания.
В целом, так и есть. Писать тесты дешевле и это ускоряет разработку в long-term плане, чем иметь много QA-мартышек, что будут везде искать регрессии.

А вот в рамках большого проекта, сколько примерно приходиться делать тестов?
Речь про абсолютное число? Это флуктирующее значение и тест-тесту рознь. один e2e тест даёт большее покрытие кода, чем 3 unit, но они тестируют разные вещи. Один тест может прогонять несколько ассертов, в то время как этот тест можно разбить на несколько мелких по одному ассерту (понятность того, что тестируем против скорости выполнения тестов).
Самое примитивное - метрика по покрытым линиям кода (LOC), но 100% покрытие гарантирует только что на каждой ветви кода существует сценарий, при котором код не падает. Однако, имея 100% LOC Coverage и контроллируя, что тесты делают то что нужно (и в нужных пропорциях, я бы сказал, что 65% Unit, 25% Integration и 10% e2e – знаю я ковбоев, что тестируют только через e2e, но получают неплохую метрику) можно очень радовать себя простотой разработки и рефактора, и конечного пользователя стабильным приложением.

Ну обычно тестируется всё публичное API моделей.
Что в целом составляет 100% бизнес логики :D

Ну это точно не для инди проектов.
Нет, это для любых проектов.

[Tails]

Ну не знай, что-то я сомневаюсь, что для небольших инди проектов, тесты действительно так нужны. Лучше потратить это время на контент, чем на создание тестов, которые отработают один раз и будут лежать мёртвым грузом. Тем более, покрывать 100% бизнес логики, это жесть. Иногда достаточно ограничиться обычным дебагером или трейсом, для проверки внутреннего состояния модуля.

[CrazyFlasher]

которые отработают один раз и будут лежать мёртвым грузом.
Тесты должны отрабатывать, каждый раз при сборке проекта

[Tails]

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

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

[dark256]

А что такое юнит-тест?

[GBee]

А что такое юнит-тест?
Такая секретная технология, что по ней инфы много, но нормального примера нет. И тот, кто ее познал почему то тоже не может внятный пример показать.

[caseyryan]

В контексте сбора приложений, грубо говоря, она должна быть всегда. Внешний консультант при заходе на проект с целью разгрести кучу мусора первым делом будет делать именно то, чтобы проект запустился с одной кнопки, или, максимум, с строго предетерминированным порядком действий (который, кстати, можно запихнуть в скрипт и вот она, одна кнопка!). Общих решений подходящих везде не существует, но для каждого отдельного проекта сборка в одну кнопку просто essential. Сравни какой-нибудь MEAN Stack и Hadoop в простоте сборке. Они вообще для разного, но со вторым можно умом тронутся пока он просто встанет. (на всякий упомяну, что мой скоуп знаний о Hadoop достаточно старый – надеюсь, многое изменилось).
Ну, речь изначально шла немного о другом. В юнити нельзя сразу открыть чистый проект и собрать его, скажем, под андроид. Но после парочки нехитрых настроек, все будет делаться именно в нажатие одной кнопки. Там это Ctrl + B или File -> Build & Run. Вот, собственно и все. Так что именно эта пресловутая "одна кнопочка" там есть, но ее надо сначала подключить. А я и написал вопрос "а где она есть?", с целью узнать где может быть такое, чтобы без настроек сразу из коробки работало. Ни разу не встречал.

[CrazyFlasher]

Юнити можно сбилдить из голых сорсов через command line интерфейс?

[Zebestov]

Такая секретная технология, что по ней инфы много, но нормального примера нет. И тот, кто ее познал почему то тоже не может внятный пример показать.
Ххаха! Точняк =)

[CrazyFlasher]

Пример простого юнит теста на flexunit:

package
{
import org.flexunit.asserts.assertEquals;

public class MyCoolModelTest
{
private var model:IMyCoolModel;

[Before]
public function setUp():void
{
model = new MyCoolModel();
}

[After]
public function tearDown():void
{

}

[Test]
public function testCountResult():void
{
model.countResult(5, 3);
assertEquals(model.result, 15);
}
}
}


public class MyCoolModel implements IMyCoolModel
{
private var _result:int;

public function countResult(a:int, b:int):void
{
_result = a * b;
}

public function get result():int
{
return _result;
}
}


public interface IMyCoolModel
{
function countResult(a:int, b:int):void;
function get result():int;
}

[GBee]

Пример простого юнит теста на flexunit:
Вот о чем и речь. Такие примеры показывают как их можно использовать, но не показывают смысла их использования.

А что за Before After?

[CrazyFlasher]

на эту тему полно книжек и инфы в гугле.
Например, если кто-то изменит чтото в логике MyCoolModel, countResult всё равно должен выдавать 15 при данных 5 и 3. Если этого не происходит, значит баг в логике. Соответственно во время сборки проекта, вылетит ошибка, что с MyCoolModel что-то не то.
Так яснее?

[wvxvw]

Давно не прикасался ни к Флешу ни к вебу вообще. Работаю в компании которая разрабатывает файловую систему в отделе инфраструктуры (пишу программы для тестирования нашего продукта, но не сами тесты).

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

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

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

Следующая ступенька - "слепые" (black box) тесты. Их пишут тестеры исходя из спецификации продукта. Как правило эти тесты имитируют взаимодействие пользователя с продуктом, занимают много времени (как минимум несколько часов в день, но может и круглый день).

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

[Psycho Tiger]

Ну не знай, что-то я сомневаюсь, что для небольших инди проектов, тесты действительно так нужны. Лучше потратить это время на контент, чем на создание тестов, которые отработают один раз и будут лежать мёртвым грузом. Тем более, покрывать 100% бизнес логики, это жесть. Иногда достаточно ограничиться обычным дебагером или трейсом, для проверки внутреннего состояния модуля.
Пример от балды: игра в дурака. Что тестируем? Метод #card.canBeat(otherCard), возвращающий true/false.
1) Что нельзя бить карту другой мастью.
2) Что можно бить карту той же мастью, но выше по рангу.
3) Что нельзя бить карту той же мастью, но ниже по рангу.
4) Что можно бить что угодно козырем.

Эти 4 теста дают неплохое покрытие для этого метода. Реализовали, запустили, тесты зелёные. Что это значит? Значит что мне не нужно тестировать это вручную больше никогда. Я всегда знаю, что метод canBeat вернёт правильный результат.
После лёгкого QA-теста выяснилось, что младший козырь может бить верхний козырь – это баг. Что я делаю? Я делаю пятый тест на этот метод:
5) Козырь нижнего ранга не бьёт козыря верхнего ранга.
Это гарантия того, что этот баг больше никогда не повторится.

Через месяц мне пришлось добавить джокеров с условиями, что джокеры бьют всё подряд. Я исправляю старый метод canBeat, добавляя в него новую логику, но тесты позволяют мне быть уверенным, что я не ничего не сломаю. Поведение старых карт относительно друг друга не изменилось.
Покрывая всё приложение тестами я могу свободно проводить рефакторинг кишков не боясь, что где-то что-то сломается. Тесты я запускаю каждый раз (имею ввиду вообще все) перед тем как сделать коммит и каждый раз после того, как я сделал что-то сложное. Например, немного поменял архитектуру и хочу узнать, как это аукнется. И я узнаю это за несколько минут, пока отхожу сварить себе кофе.

Добавлено через 3 минуты
Вот о чем и речь. Такие примеры показывают как их можно использовать, но не показывают смысла их использования.

Смысл - в простом рефакторинге и в уверенности, что новые фичи не сломают старые. Бонусом - простота разработки; например, перед тобой поставили задачу - написать калькулятор, вычисляющий длинные выражения. Единожды написав 20 тестов, которые тестируют вложенности скобок, порядок операторов, типа
1) 2 + 2 = 4
2) 2 + 2 * 2 = 6
3) (2 + 2) * 2 = 8
4) ( 2 * (3 - 2) + 4 ) * 3 = 18

ты за пару секунд узнаешь, работает ли твоя программа правильно. Вручную прогонять все 20 тестов при каждом исправлении логики... избавьте.

Добавлено через 9 минут
Следующая ступенька в тестировании: тесты интеграции. Это когда несколько "атомарных" частей кода нужно протестировать на взаимодействие. Их тоже пишут программисты, но их не запускают во время сборки, т.как сборка может легитимно не пройти такой тест.
@wvxvw Любопытно, почему сборка может не проходить интеграционный тест? Это ведь именно самый важный маркер, дружит ли система сама с собой. Если модуль А ожидает параметр int ID, а модуль B ему даёт string Name (для примера скажем, что типизация динамическая и ошибку в компайл-тайм не отследить) – то это как раз самое время сказать, что со сборкой что-то не то.

Вообще из этого краткого рассказа подход очень похож на тестирование в Google.

[wvxvw]

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

Например, не далее чем вчера, обнаружил, что на бумаге заявлено что NFS подключений к нашему серверу может быть одновременно 1000, но на практике оказалось, что не больше 200. Я пишу код NFS клиента. Поговорил с программистами, которые делают сервер - они исправили ошибку, но правки пошли в мастер ветку. Кроме мастера, есть релизные ветки, куда это изменение не пойдет, но их все еще нужно тестировать. Код, который я пишу - заказчику не отправляется, он только для внутреннего использования. Мне нет смысла писать две версии клиента - одну с учетом ошибки сервера, а другую - без. Соответственно, я просто пишу версию, которая рассчитывает на 1000 подключений и оформляю баг-репорт для серверной команды.

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

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

[Psycho Tiger]

Понятно, спасибо!

[caseyryan]

Я подозреваю, что будет тяжело опрадвать подобную бюрократию для казуальных веб игр, например.
Собственно, даже не для совсем казуальных, такая практика тоже лишний гемор.
Как по мне, так минусы юнит тестов такие:
1) Не для любого кода можно написать юнит тест. Часто все равно придется делать полную сборку проекта
2) Часто уходит много времени уже на то, чтобы приудмать как лучше написать этот тест (или как вообще его написать).

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

[illuzor]

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

[undefined]

а имеются ли какие-нибудь фреймворки для написания тестов для AS3?Когда работал тестером использовали JMeter.Основательная штука была.

[CrazyFlasher]

FlexUnit. Я же выше написал с примером.
https://cwiki.apache.org/confluence/display/FLEX/FlexUnit+Tests+and+Test+Cases

[caseyryan]

Это больше похоже на функциональность для дебажной версии, чем на тесты. То есть, собственный код игры, а не внешний тестирующий код. Мы подобное всегда называли читами. Естественно, в релизной версии все читы вырезаются. Или почти все ;)
Нет, это именно внешний тестирующий код

[Zebestov]

Мне показалось, или никто здесь так и не упомянул одного из самых ярких "бросальцев" BlooDHounD?

[caseyryan]

А он чем занялся? Случаем не ирландским пабом? :D

[Zebestov]

Ага :) пожалуй, самый правильный "бросок"!

[СлаваRa]

наверное, именно поэтому он не так давно выкатил несколько апдейтов своей крипто либы

[Zebestov]

Ностальгию еще никто не отменял :)

[drf]

Разработку мини флеш игр два года как в хобби перенёс. За 10 лет общения с разными типами клиентов на фрилансе стал психологом(экзистенциальным философом). Теперь основа пси-фриланс.

[ZackMercury]

экзистенциальным философом
Ими не стают, ими рождаются XD

[caseyryan]

Ими не стают, ими рождаются XD

а я считаю, что только наследниками дворянских титулов рождаются, всеми остальными становятся :D

[ChuwY]

У меня вопрос к топикстартеру.
А вы собственно программистом поработать за деньги успели?

[zackscript]

У меня вопрос к топикстартеру.
А вы собственно программистом поработать за деньги успели?
Ну если честно то за деньги еще не доводилась - это раз , два - это мое увлечение , просто я это делаю и учусь для себя а вопрос был поднят из-за того что мне это дело временами где-то трудно давалась а где-то легко но мне это нравится. А если Вы скажите что мол: "программирование - это профессия" то помнится мне кто-то написал что это - стиль жизни :)

[undefined]

А если Вы скажите что мол: "программирование - это профессия" то помнится мне кто-то написал что это - стиль жизни
это скорее стиль мышления, не думаю что это можно взять и бросить(вариант об стену головой не рассматриваем :D)

[Sintesis]

Да не, как можно такое бросить, такому делу чаще вся жизнь посвящается, так оно и денег приносит и очень интересно!

[Кот Баюн]

Я пару раз на этом зарабатывал, но в данный момент бросил, да.
Несмотря на то, что два IT-образования, и оба программисткие.
Честно говоря, мне не очень это нравится, да и с математикой нелады.

Я больше рисовать люблю.

[ZackMercury]

так оно и денег приносит и очень интересно
Всё может и денег приносить и быть очень интересным.
Не интересно только то, что мы не в состоянии понять и то, что вызывает когнитивные диссонансы)
Программирование берёт не тем, что оно интересно.
Программирование позволяет нам развивать мозг, помогает развитию логического мышления, а затем эти навыки можно применить собственно в чём угодно, что граничит с наукой или искусством.

[Sintesis]

Программирование берёт не тем, что оно интересно.

Это уж кого как берёт. Мне очень интересно, а то бросил бы быстро. Вот уже лет восемь оторваться не могу. Начиналось всё с этого форума, с поделок на альтернатива 3D. Потом у ребят отсюда поднабирался опыта, Волш, СлаваРа, Дикобраз, Удафф вечно отвечали на мои туповатые вопросы, вот спасибо! 4 года фриланса, 2 года аутсорса, а теперь уже и в офисе огромной международной компании уже год работаю с билдами, брэнчами, препродами, продами, тэстам, скрамом, с персоналом в 200 человек. Норм так-то, правдо да в большой компании немного рутинно всё становится, не на столько интересно, но тоже ничего.

[Max_Payn]

и ваши проекты на флеше? :)

[ZackMercury]

Sintesis, интересно всё, если увлекаться. Интерес - это воспоминания об эндорфине и серотонине, выделяющихся при выполнении каких-то действий, при успешном получении каких-либо навыков, углублённом понимании либо завершении проектов. Типа выполнил ачивку - мозг тебя похвалил.
Вы пробовали что-то другое кроме программирования? Если вам было не интересно, это значит, что вы просто этого не до конца понимали.

[Sintesis]

и ваши проекты на флеше? :)
У компании не только на флеше, есть ещё и под мобилы они не на флеше, а вот для браузеров на флеше. Но сейчас сказали, что за пол года нужно выучить haxe. С флешем заканчиваем, эх

[СлаваRa]

Haxe - это следующий уровень флеша, не переживай он тебе понравился куда больше :)

[caseyryan]

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

[undefined]

СлаваRa,haxe славится кросс-компиляцией.Каковы её возможности? Если используется только DL,он сможет это на js переложить?

[Max_Payn]

интересно по Haxe создать отдельную ветку, пусть каждый скажет свое мнение

[СлаваRa]

через неделю будет online конференция, там вы сможете узнать ответы на все вопросы)

[Max_Payn]

где смотреть? и когда примерно?

[СлаваRa]

ruHaxe online конференция №5 (http://haxe.ru/ruhaxe-online-konferentsiya-5)

[undefined]

а трансляция будет? Для иногородних студентов.

[СлаваRa]

Она будет для всех, видео потом будет доступно на youtube

[Max_Payn]

СлаваРА один из выступающих ;) . С 2005 года существует НАХЕ, а вот явного продвижения не видно, не видно примеров

[СлаваRa]

Зачем каверкать мое имя? А по делу, может быть вы не туда смотрите или надо все столбы на районе обклеить?

[Max_Payn]

Сорри, поправил. Будем вас слушать 24 :)