Как стать автором
Обновить
13
Карма
0
Рейтинг
Владимир @vovkab

Пользователь

Дизайн мобильных приложений: почему мы работаем в @1x

> я скорее о svg

Тут есть 3 способа:
1. экспортировать как есть, но получим размытые картинки, обычно на hdpi
2. экспортировать все размеры в png и руками подправить иконки для hdpi, tvdpi и тд.
3. создать отдельную копию svg для hdpi, подвинуть ее по сетке что бы избавится от блюра.

Мне больше нравится третий вариант, так как он легче и к тому же у нас уже все нарезается из svg автоматически. В итоге из mdpi svg мы получим png для mdpi(x1), xhdpi(x2), xxhdpi(x3). А из hdpi.svg -> hdpi.png.

Дизайн мобильных приложений: почему мы работаем в @1x

> Не совсем понял этот момент, если у вас нарезаются из svg все нужные размеры, то зачем отдельный svg для hdpi?

Для того что бы избавиться от блюра. У вас даже пример есть с красным кружочком. С «фигурными» иконками, там особо смысла нет, так как мало что можно сделать, и там не так заметно.

> По поводу текста, в спецификациях мы отдаём расстояние до базовой линии, на не лэйбла. Иногда даём картинку с сеткой вроде вот такой:

Сетка это хорошо, но я не совсем понимаю как она помогает. Программисты сами все равно вычисляют коректный падинг?

Дизайн мобильных приложений: почему мы работаем в @1x

Делаем в принципе все тоже самое, вот уже пару лет. (андроид)
Работаем со скетч фалом напрямую, оттуда сохраняем svg. Gradle плагин (https://github.com/avianey/androidsvgdrawable-plugin) нам нарезает все нужные размеры. Если у иконки есть ровные линии, то делается отдельный svg файл для hdpi, если сильно заметно.

Мне интересно что вы делаете с редлайнами для текста, например, то что показано на картинке «Пример работы скрипта Size Marks», не будет работать, так как не учитываются падинги для шрифтов. В примерe падинг сверху уже будет не 60, а 54, в добавок судя по картинке оба текстовых поля пересекаются друг с другом. Не знаю как в ios, в андроиде такого быть не должно :)

Приемы разработки ASMX веб-сервисов

searchsoa.techtarget.com/definition/REST

REST (REpresentational State Transfer) is an architectural style, and an approach to communications that is often used in the development of Web services. The use of REST is often preferred over the more heavyweight SOAP (Simple Object Access Protocol) style because REST does not leverage as much bandwidth, which makes it a better fit for use over the Internet. The SOAP approach requires writing or using a provided server program (to serve data) and a client program (to request data).

Процесс Code Review с Atlassian Stash

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

И это я только вечер с ним провёл :)
V3.5.0

Android 5 vs Kids

Он есть на локскрине, правда все равно надо 1 свайп и 2 клика :)

Дергаем шторку -> клик по текущему пользователю -> выбираем нового.

Лайфхаки ручного тестирования на мобилках от 2ГИС — Доклад с конференции SQA Days 15

Ну как то совсем тяжко и уныло.

1. Под андроид полно тест фрэймворков, начиная от стандартных, Android Test (Espresso), UI Automator, Unit Test, заканчивая Robolectric, Appium и тд. На худой конец можно использовать, adb shell sendevents…
2. Зачем ездить по городу, когда есть Mock Locations? (http://developer.android.com/training/location/location-testing.html)
3. Зачем возьня с qr-кодами, когда можно использовать что то типа Hockeyapp, на худой конец накидать свой тест апп.
4. Почему нет подключенной краш статистики, сидите и ждете пользователей, когда напишут вам письмо? Если пользователь решит вам что то писать, -1 вам в гугл плэй обеспечен.
5. Почему ничего не сказано про поэтапное внедрение на Google Play? Ах да, зачем, смысла в же нет, у вас же нет краш статистики, в ней же ничего не понятно.

Лайфхак — займитесь автоматизированным тестированием.

Фрагментация Android практически перестала быть проблемой?

Складывается впечатление, что ios разработчики волнуются за андроид фрагментацию больше, чем сами адроид разработчики :)

6 мифов, мешающих разработчикам использовать Git

Видимо вот для таких вот случаев. Еще и бинарей туда напихают для терабайтности :)

6 мифов, мешающих разработчикам использовать Git

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

6 мифов, мешающих разработчикам использовать Git

не нужно лишних веток, для этого всего есть git rebase

6 мифов, мешающих разработчикам использовать Git

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

1. Если это рабочая репа, то всегда будет видна история, легко найти комит который что то ломает, так же легко перенести отдельные комиты в другие ветки, мержить намного легче, в общем все лучше :)
2. Если от вас требуется, как при отправке в герит, «патч файл», дублируем ветку, сливаем все комиты в один и отправляем. Что то надо доработать? У вас всегда есть исходная ветка, легко мержимся/ребэйзимся, и далее все заново.

6 мифов, мешающих разработчикам использовать Git

Видите, за то теперь есть причина для самосовершенствования :)

6 мифов, мешающих разработчикам использовать Git

Тут обсуждают даже не то что, что то залили в мастер, а вообще в нужности системы контроля версии, и это пишут программисты, лол :)

Сразу определимся что, наживую в мастер ни кто ничего не льет, он только для релизов, все фичи по отдельным веткам, и потом мержатся с --no-ff в дев. И далее по git flow.

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

6 мифов, мешающих разработчикам использовать Git

Все зависит от вашей схемы ветвления.
Если вы по сути один, то по этому и лепите все в мастере. Если будете не один тогда прийдут все эти ветки.
Вот тут хорошее описание про один из способов использования гит веток: nvie.com/posts/a-successful-git-branching-model/

6 мифов, мешающих разработчикам использовать Git

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

6 мифов, мешающих разработчикам использовать Git

Вы не путаете комиты с пушем в удаленный репозиторий? Думать над именем комита можно и позже и комитить сколько влезит пока все не сделаешь. А уже в конце перед пушем все почистить, написать сообщения для комитов или вообще все комиты заново нарезать.

6 мифов, мешающих разработчикам использовать Git

У вас ответ как у менеджера или клиента. Какие нафиг рефакторинги, какой код, какая еще спецификация мне просто нужна работающая программа.

Автомобили. Это если вы спроектировали и сделали, скажем, дверь для машины, принесли, а уже все поменялось, и вас просят исправить все крепления да и вообще всю форму двери что бы она подходила к новой машине.

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

Аспектно ориентированное программирование в Android

А как у этой штуки на счет производительности, тестируемости и поддерживаемости?

Боитесь ли вы Gradle так как боюсь его я?

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

Информация

В рейтинге
Не участвует
Откуда
California, США
Дата рождения
Зарегистрирован
Активность