Пока — только удаленные. :-) Но резюме принимаются. Если в течение года надумаете в наши края — welcome (ничего, что я на местном деревенском диалекте?)
Не, не с моим-то везением. :-) Весной (в сентябре) ездил в Кэрнс — на недельку с хвостиком. Маловато времени оказалось, до Lizard Island добраться не удалось, только на Green Island — это один из редких рифов, на котором есть растительность и сухопутная живность. Вообще Северный Куинслэнд — это одновременно и мечта исследователя, и (комфортный) экстрим, и просто райское местечко.
Учтите, что цивилизации рядом — никакой. Ближайший, с позволения сказать, город — Куктаун, более чем в 100 км по воде. Ближайшие поселения — на мысе Йорк, большей частью — аборигенские, не самые богатые, скажу вам. Развлечения — это в Кэрнс, это еще в километрах 450-ти (по австралийским меркам — недалеко).
В рифах крупных акул почти нет, крокодилы тоже от побережья недалеко отплывают, единственная неприятность — медузы blue bottle, да и они бывают всего пару-тройку месяцев в году. Циклоны иногда захаживают в гости, но это дело местные лечат пивом: о циклоне сообщают заранее, всем (кроме полиции и других экстренных служб) дают длинные выходные, народ закупается пивом и идет в гости к друзьям, что живут на холмах, на 3-4 дня. Так что приспособиться можно.
сидишь себе на берегу океана с ноутом и пишешь код
Так в чем дело? Можно поехать в Cairns (Queensland, Australia) — вполне то, что надо. Лето — 10 месяцев в году (хотя есть и влажный сезон), работа — есть, экзотики (типа морских крокодилов) — хоть отбавляй. Сам подумывал так сделать. Один минус — не сильно это к работе располагает, расслабиться хочется. :-) А еще девушки в бикини на все вкусы — короче, работать тяжело. Хотя, возможно, откроем там офис — на 3-4 месяца в году, когда в Сиднее холодно…
Молнию можно заменить «липучкой»-velcro — тогда ничего «жеваться» не будет. Только какие будут акустические эффекты при раздевании! Соседи точно будут в курсе событий.
Интересно, разве из интернета можно брать музыку нелегально? Нелегально — выкладывать чужую музыку в инет, а вот скачивать из публичного доступа — не возбраняется законом.
Сайт, вроде, неплох. Только вот почему при голосовании на главной страницу пункты на английском, а ссылки «Голосовать» — на русском? А если «ай донт спик энд рид Рашн»? Куда жать?
Фруктовые мушки — на лимоны? Cладкие у Вас лимоны, скажу Вам! Повезло… :-)
Где-то с год назад мы с сыном сделали подобную батарею из 2 лимонов и запитали ею светодиод. Недели 2 горел, пока не выбросили лимоны — надоело. Но эффект, конечно, был замечательный: все друзья-знакомые искали подвох, даже подсчитывали, сколько электроэнергии можно получить с одного лимонного деревца.
Да, работа над JOIN'ами идет, так что ждать не очень долго. Так же ведется работа над сложными объектами (точнее, над эффективной системой их хранения и поиска).
Что для Вас было бы важнее — JOIN'ы или сложные объекты? Или что-то еще? Спасибо!
Открою еще один секрет — мы работаем над потоками бинарных данных, которые можно будет хранить в базе и получать обратно также в виде потока. С помощью фильтров можно будет добавить возможность сжатия бинарных данных.
Сама база по умолчанию не сжимает данные, т.к. ее основная цель — скорость, а сжатие несколько противоречит этой идее.
Буду рад помочь, если возникнут вопросы по базе. В любом случае, буду вести этот блог, по мере возможностей добавляя новые статьи об объектном проектировании.
Функциональность для SELECT Publisher FROM Paper будет добавлена чуть позже, возможно, с LINQ и/или EF (хотя, скорее всего, независимо от них).
Delete, Insert и Update реализованы как методы, принимающие объекты в качестве параметров — все же база объектная. С добавлением сложных объектов в основной функционал BULK INSERT можно будет делать, помещая в базу коллекцию объектов — например, object[], что позволит не только вставлять объекты разных типов одновременно, но и позволит реализовать нечто вроде BULK UPDATE и BULK DELETE для объектов любого типа.
Данные хранятся на сервере, и каждый пользователь имеет доступ к данным. Для доступа нужен только клиент (.NET-сборка — она использует .NET 2.0 SP1, т.е. в качестве клиентской ОС можно использовать все Windows от 2000 и старше), который можно скачать отдельно.
Мне приходится забегать вперед и писать о том, что мы еще не закончили или даже только собираемся делать, но, видимо, это отличительная черта хабровчан — смотреть в будущее, что не может не радовать. :-) Мы работаем над т.н. «фильтрами» — специального вида классами, которые преобразовывают данные для хранения и/или индексирования в специальном виде. К примеру, один из фильтров — кстати, один из самых простых — преобразует тексты в набор слов в «упрощенном» виде для полнотекстового поиска, правда, пока только на английском. Но мы собираемся выложить интерфейсы фильтров и их исходные тексты в общий доступ и продолжать их разработку в open-source сообществе, так что стоит ожидать появления версии и для русского языка, и других.
Те же фильтры могут выполнять роль хранимых процедур (stored procedure), и возвращать данные в уже преобразованном виде, к примеру, как XML. Эти фильтры могут быть привязаны к одной базе или быть доступными всем базам на данном сервере.
Да, верно, это сработало бы для полей, но не для свойств (properties), которые могут быть «только для чтения» (read-only) или вычисляемыми из нескольких других полей или свойств. Этот вариант у нас частично реализован, но отключен из-за «неинтуитивности».
Многочисленные беседы с программистами показали, что большинство ожидает, что запрос SELECT Publisher FROM Paper вернет массив string[], а запрос SELECT Publisher, CopiesPublished FROM Paper должен вернуть массив экземпляров динамического класса типа
{string Publisher, int CopiesPublished }[].
Как Вы считаете, является ли этот путь более «интуитивным» и/или корректным?
что не совсем точно определяет проблему. А проблема в том, что C# (как и многие другие мейнстрим-языки .NET) не допускает динамических типов во время исполнения, т.е. компилятор должен знать, какой тип вернет тот или иной метод, или к какому типу выполнить приведение (type casting). Поэтому запросы сейчас возвращают только экземпляры классов, но не отдельные их поля или свойства. При использовании LINQ компилятор сам генерирует возвращаемые классы во время компиляции, т.е. опять нет динамической типизации. В C# 4.0 появилась возможность использовать динамические типы, так что полноценный SELECT… FROM — не за горами.
В данном случае Вы имеете дело с базой данных напрямую, без MS SQL Server'а (который, кстати, нужно лицензировать отдельно), поэтому нет дополнительных слоев доступа к данным, которые замедляют работу (и иногда нарушают логику объектов). Eloquera манипулирует объектами напрямую — ради скорости.
Microsoft прекращает развитие Linq2SQL (не самого LINQ, конечно) из-за неудовлетворительного качества SQL-кода и необходимости прямого доступа к таблицам. Entity Framework — хорошая штука, требующая, правда, генерации файлов описания данных, что делает обновление схемы несколько муторным занятием. NHibernate — это классический O/R Mapper со всеми вытекающими отсюда потенциальными проблемами.
Eloquera будет поддерживать LINQ (мы работаем над этим), и поддерживать его эффективно, без генерации SQL, поскольку LINQ — практически идеальный язык для объектных запросов. В планах так же есть поддержка EF, а также других объектных платформ (к примеру, Java). Опять же, благодаря непосредственной работе с объектами, многие «родовые» проблемы LINQ2SQL и EF решаются довольно эффективно.
Да, мы рассматриваем и такой вариант. Но основной сценарий предполагает написание «родного» Java-сериализатора объектов, т.к. в таком случае скорость обработки данных повышается в разы.
Ну, на сортировку байтов так много времени не нужно, можно просто взять массив long[256] и просто посчитать, сколько каждого байта нам повстречалось. А потом записать — если нужно. Можно распараллелить — будет быстро. :-)
В рифах крупных акул почти нет, крокодилы тоже от побережья недалеко отплывают, единственная неприятность — медузы blue bottle, да и они бывают всего пару-тройку месяцев в году. Циклоны иногда захаживают в гости, но это дело местные лечат пивом: о циклоне сообщают заранее, всем (кроме полиции и других экстренных служб) дают длинные выходные, народ закупается пивом и идет в гости к друзьям, что живут на холмах, на 3-4 дня. Так что приспособиться можно.
Так в чем дело? Можно поехать в Cairns (Queensland, Australia) — вполне то, что надо. Лето — 10 месяцев в году (хотя есть и влажный сезон), работа — есть, экзотики (типа морских крокодилов) — хоть отбавляй. Сам подумывал так сделать. Один минус — не сильно это к работе располагает, расслабиться хочется. :-) А еще девушки в бикини на все вкусы — короче, работать тяжело. Хотя, возможно, откроем там офис — на 3-4 месяца в году, когда в Сиднее холодно…
Где-то с год назад мы с сыном сделали подобную батарею из 2 лимонов и запитали ею светодиод. Недели 2 горел, пока не выбросили лимоны — надоело. Но эффект, конечно, был замечательный: все друзья-знакомые искали подвох, даже подсчитывали, сколько электроэнергии можно получить с одного лимонного деревца.
Что для Вас было бы важнее — JOIN'ы или сложные объекты? Или что-то еще? Спасибо!
Сама база по умолчанию не сжимает данные, т.к. ее основная цель — скорость, а сжатие несколько противоречит этой идее.
Буду рад помочь, если возникнут вопросы по базе. В любом случае, буду вести этот блог, по мере возможностей добавляя новые статьи об объектном проектировании.
SELECT Publisher FROM Paperбудет добавлена чуть позже, возможно, с LINQ и/или EF (хотя, скорее всего, независимо от них).Delete, Insert и Update реализованы как методы, принимающие объекты в качестве параметров — все же база объектная. С добавлением сложных объектов в основной функционал BULK INSERT можно будет делать, помещая в базу коллекцию объектов — например,
object[], что позволит не только вставлять объекты разных типов одновременно, но и позволит реализовать нечто вроде BULK UPDATE и BULK DELETE для объектов любого типа.Мне приходится забегать вперед и писать о том, что мы еще не закончили или даже только собираемся делать, но, видимо, это отличительная черта хабровчан — смотреть в будущее, что не может не радовать. :-) Мы работаем над т.н. «фильтрами» — специального вида классами, которые преобразовывают данные для хранения и/или индексирования в специальном виде. К примеру, один из фильтров — кстати, один из самых простых — преобразует тексты в набор слов в «упрощенном» виде для полнотекстового поиска, правда, пока только на английском. Но мы собираемся выложить интерфейсы фильтров и их исходные тексты в общий доступ и продолжать их разработку в open-source сообществе, так что стоит ожидать появления версии и для русского языка, и других.
Те же фильтры могут выполнять роль хранимых процедур (stored procedure), и возвращать данные в уже преобразованном виде, к примеру, как XML. Эти фильтры могут быть привязаны к одной базе или быть доступными всем базам на данном сервере.
Многочисленные беседы с программистами показали, что большинство ожидает, что запрос
SELECT Publisher FROM Paperвернет массивstring[], а запросSELECT Publisher, CopiesPublished FROM Paperдолжен вернуть массив экземпляров динамического класса типа{string Publisher, int CopiesPublished }[].Как Вы считаете, является ли этот путь более «интуитивным» и/или корректным?
SELECT * FROM Paper
вполне работают.
Вы правы, если исполнить запрос вида
SELECT Publisher FROM Paper
то система вернет ошибку
FROM functionality is not implemented yet,
что не совсем точно определяет проблему. А проблема в том, что C# (как и многие другие мейнстрим-языки .NET) не допускает динамических типов во время исполнения, т.е. компилятор должен знать, какой тип вернет тот или иной метод, или к какому типу выполнить приведение (type casting). Поэтому запросы сейчас возвращают только экземпляры классов, но не отдельные их поля или свойства. При использовании LINQ компилятор сам генерирует возвращаемые классы во время компиляции, т.е. опять нет динамической типизации. В C# 4.0 появилась возможность использовать динамические типы, так что полноценный SELECT… FROM — не за горами.
Берегите мозг — говорят, без него тяжело! :-)
В данном случае Вы имеете дело с базой данных напрямую, без MS SQL Server'а (который, кстати, нужно лицензировать отдельно), поэтому нет дополнительных слоев доступа к данным, которые замедляют работу (и иногда нарушают логику объектов). Eloquera манипулирует объектами напрямую — ради скорости.
Microsoft прекращает развитие Linq2SQL (не самого LINQ, конечно) из-за неудовлетворительного качества SQL-кода и необходимости прямого доступа к таблицам. Entity Framework — хорошая штука, требующая, правда, генерации файлов описания данных, что делает обновление схемы несколько муторным занятием. NHibernate — это классический O/R Mapper со всеми вытекающими отсюда потенциальными проблемами.
Eloquera будет поддерживать LINQ (мы работаем над этим), и поддерживать его эффективно, без генерации SQL, поскольку LINQ — практически идеальный язык для объектных запросов. В планах так же есть поддержка EF, а также других объектных платформ (к примеру, Java). Опять же, благодаря непосредственной работе с объектами, многие «родовые» проблемы LINQ2SQL и EF решаются довольно эффективно.
P.S. Сорри за невольный педантизм.