Пользователь пока ничего не рассказал о себе

Достижения

Все достижения (6)

Наибольший вклад в теги

Все теги (40)

Лучшие ответы пользователя

Все ответы (37)
  • Когда видимость метода стоит установить private, а когда — protected?

    Zigmar
    @Zigmar
    Если явно не надо делать protected (например метод переопределив который, вы позволите пользователю модифицировать поведение) — делайте private. На «всякий случай» делать protected — это по крайней мере странно, это все равно, что на всякий случай делать все public. Вообще, если вы пишете библиотеку, то так-же как вы определяете, что будет публичным интерфейсом (public) а что имплементацией (private), введите еще одну сущность — интерфейс для наследников. С таким делением (интерфейс для всех/интерфейс для наследников/детали имплементации) все должно стать более или менее понятно.
    Ответ написан
  • lua - практическое применение?

    Zigmar
    @Zigmar
    Луа, будучи, очень простым и компактным языком — легко встраиваться. Включаете пару десятков чистых сишных файлов в проект — и вуаля — у вас встроеный язык. Еще, настраиваемость — по большому счету, в плане библиотек, луа это скорее скелет языка, чем полноценный язык програмирования. Иногда при встраивание вообще выкидвают большую часть (или всю) «стандартную» библиотеку, заменяя ее специализированной под домейн, фактически создавая специализированный язык. Еще один плюс — компактность. Я как-то давно, проверял возможность запускать луа-интерпретатор в качестве отладочного модуля на встроенном чипе (я не говорю про смартфоны, а про «жесткий» embedded). Так вот, виртуальная машина луа (правда почти без библиотек и без интерпретатора, кормить ей надо было уже байткод) занимала 15кб (!) RISC кода. Оказалось, что вполне реально запустить было на том железе, хотя в конце эту идею зарубили как слишком сумашедшую («интепретатор в нашем RT?!»). Идем дальше, Луа можно использовать в качестве декларативного языка, но с «плюшкой» в виде динамичности и читаемости человеком, в отличии скажем от статических декларативных систем, например XML. Я как-то делал декларативную систему описания автоматических тестов на луа, получилось по-моему, неплохо. :) А из более простых примеров такого применения — это файлы конфигурации. Простые файлы var=value легко распарсить вручную, на зато на луа можо сделать вот так:
    width = 100
    height = width*1.2
    positions[0] = {x=0, y=height-20 }

    Причем реализуется буквально в пару строчек со стороны хоста — инициализовать луа, запарсить и выполнить скрип, считать получившиеся глобальные переменные, все.

    Вообщем давайте просуммируем: если нужен легко встраиваемый, компактный, настраиваемый и быстрый скриптовый язык, чтобы расширить функциональность вашей программе — луа отлично для это подходит. Но если нужный полноценный самостоятельный язык, c богатой библиотекой и возможность писать приложения от начала до конца, то лучше посмотреть в сторону «серьёзных» собратьев, скажем Пайтона (Perl, Ruby, whatever). Их, кстати, тоже можно встроить в качество скриптового языка, просто это далеко не всегда оправданно там, где можно ограничится луа.

    Вот.

    ЗЫ: JavaScript в чем-то похож на луа тем, что он тоже почти никогда не используется как «самостоятельный» язык.
    Ответ написан
  • Преимущества систем контроля версий, альтернативных SVN?

    Zigmar
    @Zigmar
    В качестве полуюморного ответа послушайте презентацию Линуса Товардса про git: Google Tech Talk: Linus Torvalds on git. Смешно, хотя очень догматично — Линус считает любую централизованную VCS злом и преступлением против человечества.

    Сам я, несколько лет активно работал с SVN — последнюю фирму я сподвигнул перейти на SVN c VSS, в результате чего администрирование тоже свалилось на меня. Сейчас перешел на Mercurial — и очень доволен, возвращается не собираюсь, просто потому он дает все то, что дает SVN плюс много. Из преимуществ:

    1) Надежность #1. Конкретно в SVN часто приходится делать cleanup, unlock, решать проблемы вроде той, если кто-то случайно переносит директорию вместе .svn, неконсистентные деревья (когда версии поддиректорий отличаются) и т.д. В Mercurial я с таким не сталкивался.
    2) Надежность #2. Умерший сервер в централизованной VCS — это серьёзная проблема, при отсутствие своевременного бекапа — это глобальная катастрофа. В распределенных системах — каждый клон — это фактически бекап всего репозитория.
    3) Ветки. Все кто работал с SVN, знает какая это страшная головная боль. Создавать их действительно очень лего, мержить — страшный геморрой. В распределенных системах это, как правило, намного проще и надежнее.
    4) Независимость от сервера. Очень полезно при удаленной работе.
    5) Локальные чек-ины (коммиты). С SVN, чтоб сохранять промежуточные шаги, не ломая другим рабочую ветку, надо создавать свою ветку, которую потом мержить (что в SVN, как известно, не слишком удобно). На практике, я наблюдал, что многие просто не коммитят, пока не заработает — иногда это дни или даже недели работы. Возникает вопрос — нафига тогда VCS нужна? В распределенных системах можно в локальный репозиторий коммитить сколько душе угодно, хоть 100 раз в день, а когда готово, сделать push изменений в общий репозиторий.
    6) Гибкость. Распределенные системы дают несколько разных способов организации работы, включая работу с центральным репозиторием (а-ля SVN), куда все «сдают» изменения. При этом, каждый у себя или в группах девелоперы могут организовывать работу по своему. Централизованные системы навязывают один способ работы с минимум гибкости.
    Ответ написан
  • На каком языке пишут программы для Android

    Zigmar
    @Zigmar
    Родной язык Андроида (как это ясно видно из документации) — это Java. Весь API к платформе предоставлен в виде Java библиотек. Впрочем, на самом телефоне бежит не джава — джававский байткод интерпретируется в родной андроидовский (Dalvik), который и запускается на аппарате. Кроме этого, есть NDK (native development kit) — набор инструментов и библиотек, которые позволяют скомпилировать нейтивный позикс (Линукс) код и прицепить это к аппликации. Соответственно, там может бежать все, что компилируется в нейтевный код, включая интерпретаторы скриптовых языков и виртуальные машины. До недавнего времени, нельзя было создать приложение полностью в нейтивном коде — все равно нужна была обертка из Java, недавно, добавив набор нейтивных библиотек с системными API стало возможно написать нейтивную программу от начала до конца, без Java.

    Из вышеперечисленного ясно, что можно писать практически на чем угодно. В реальности же, в большинстве случаев, пишут на Java, иногда цепляют переписанные узкие места и/или сторонние библиотеки на С/С++. Исключения — игры, которые часто пишут целиком или почти целиком на С++.
    Ответ написан

Лучшие вопросы пользователя

Все вопросы (1)