JTAGICE2 — очень мне нравился — 15600р в терре
ULINK2 — 13100р в терре
а если занятьcя программированием крутых DSP какихнить, то там и по 100к есть отладчики, например, BH-USB-56 — 120000р в терре, с ними можно графики красивые рисовать )
keil и iar хорошие среды, особенно если купить фирменный программатор за (500-1000+$$$)
вот только все это денег стоит немалых… но зато включил — работает )
всегда писал в Eclipse
правда надо было сильно помучится, чтобы все заработало… но зато потом и прошивка одной кнопочкой и отладка мышкой из гуя с брейкпойнтами… )
Даже для пользователей App Engine (которым я тоже являюсь) доклад показался странным. Он сначала упомянул, что есть RPC и REST, а потом очень долго рассказывал про картинки с аннотациями, и всевремя говорил как все круто/хорошо, хотя понять что крутого и хорошего было невозможно, если только сам до этого не мучался с созданием REST приложений с нуля… думаю надо поработать над структурой доклада и аннотациям уделить минут 10, а остальное время уделить более высокоуровневым и ценным практичеким приемам заработки RESP приложений.
респект организаторам, кофе в костюме с бабочкой мне еще ни на одной конференции не наливали )
доклады тоже были неплохие, а некоторые очень даже хорошие… только чел из Баку не порадовал совсем, я сейчас даже не могу ничего полезного из его рассказа вспомнить…
майкой тоже разжился )
в onDraw нужно только нарисовать вьюшку на канве и все. Вызывая invalidate вы постоянно заставляете перерисовываться вьюшку, даже если ей этого и не надо. Invalidate нужно вызывать из других мест, когды вы хотите, чтобы вид обновился. Вызов Invalidate, в свою очередь, запланирует перерисовку вьюшки.
Можно немного оптимизировать:
Чтобы ловить лонг пресы используется обычно Runnable и функция postDelayed(Runnable, время_долгого_нажатия) Handler'а. Из Runnable, когда он будет выполнятся, нужно будет посмотреть, если палец никуда не двинулся — значит лонг прес. Жалко таймер постоянно крутить )
так быстрее это же работать не будет.
Там внутри так же как у автора: начинается транзакция, выполняются все команды, заканчивается транзакция… зато надо контент провайдеры городить, которые иногда совсем не кстати.
Если нет 500 страничной документации на проект, то переписать какие-то части придется, потому что все постоянно меняется и ничего до конца не ясно, ни заказчику, ни тем более менеджеру.
Часто во многих местах пишется говнокод. А потом, переправленный на сто раз и весь в заплатках говнокод, переписывается, когда заказчик доволен всем и это оказывается именно то что он хотел.
до стилей в терминологии Андроида вы не довели дело, а было бы хорошо сделать стили для кнопок и бутстреп тему для приложения ) урок был бы намного содержательнее.
А у меня есть свой репозиторий )
Преподаю программирование по субботам с утреца… а когда студенты узнают, что я на работе еще и играми занимаюсь — к каждому слову прислушиваются =)
Вы проделали отличную работу, спасибо большое за статью, узнал много нового.
Но хочется узнать как закодить правильно… в Java без synchronized/volatile флажок mtx_locked бы не работал. А как правильно это сделать в С++, чтобы точно всегда работало? Сейчас почти все процессоры многоядерные и у каждого ядра свой кеш. А volatile очень снижает производительность чтения/записи.
с этим никто не спорит, мне интересно, есть ли баг в приведенном в статье коде. На С++ я немного программировал, поэтому я не могу точно сказать… но ИМХО, нет гарантии, что актуальное состояние флага mtx_locked видят все потоки…
Например, может ли другой поток закешировать у себя значение mtx_locked большее нуля и вообще перестать пытаться лочить мьютекс (некоторое время или вообще навсегда) и начнет крутиться только в вайле?
а разве не надо писать static volatile int mtx_locked = 0, намекнув компилятору, что mtx_locked хитрый флаг, изменяемый из разных потоков? прокомментируйте пожалуйста.
ULINK2 — 13100р в терре
а если занятьcя программированием крутых DSP какихнить, то там и по 100к есть отладчики, например, BH-USB-56 — 120000р в терре, с ними можно графики красивые рисовать )
вот только все это денег стоит немалых… но зато включил — работает )
правда надо было сильно помучится, чтобы все заработало… но зато потом и прошивка одной кнопочкой и отладка мышкой из гуя с брейкпойнтами… )
доклады тоже были неплохие, а некоторые очень даже хорошие… только чел из Баку не порадовал совсем, я сейчас даже не могу ничего полезного из его рассказа вспомнить…
майкой тоже разжился )
в onDraw нужно только нарисовать вьюшку на канве и все. Вызывая invalidate вы постоянно заставляете перерисовываться вьюшку, даже если ей этого и не надо. Invalidate нужно вызывать из других мест, когды вы хотите, чтобы вид обновился. Вызов Invalidate, в свою очередь, запланирует перерисовку вьюшки.
Можно немного оптимизировать:
Чтобы ловить лонг пресы используется обычно Runnable и функция postDelayed(Runnable, время_долгого_нажатия) Handler'а. Из Runnable, когда он будет выполнятся, нужно будет посмотреть, если палец никуда не двинулся — значит лонг прес. Жалко таймер постоянно крутить )
Там внутри так же как у автора: начинается транзакция, выполняются все команды, заканчивается транзакция… зато надо контент провайдеры городить, которые иногда совсем не кстати.
спасибо.
Часто во многих местах пишется говнокод. А потом, переправленный на сто раз и весь в заплатках говнокод, переписывается, когда заказчик доволен всем и это оказывается именно то что он хотел.
Преподаю программирование по субботам с утреца… а когда студенты узнают, что я на работе еще и играми занимаюсь — к каждому слову прислушиваются =)
Но хочется узнать как закодить правильно… в Java без synchronized/volatile флажок mtx_locked бы не работал. А как правильно это сделать в С++, чтобы точно всегда работало? Сейчас почти все процессоры многоядерные и у каждого ядра свой кеш. А volatile очень снижает производительность чтения/записи.
Например, может ли другой поток закешировать у себя значение mtx_locked большее нуля и вообще перестать пытаться лочить мьютекс (некоторое время или вообще навсегда) и начнет крутиться только в вайле?