вторник, 26 апреля 2011 г.
Есть желающие стать Junior Java Developer в EPAM?
Лаборатория пока не распределённых систем, а учебная. Ответственен в том числе за подготовку Junior Java Developer (D1). Новость следующая - в период 15июня-15сентября в харьковском офисе EPAM будет работать так называемая Pre-prodaction program:
1. Как попасть?
- прислать мне на Golovach.Ivan@gmail.com резюме (главное: Ваш уровень английского, что писали/изучали в институте)
- выполнить ряд заданий (на написание нескольких сот строк кода на Java), которые я вышлю в ответ на резюме
- выслушать мои замечания на выполненные задания и исправить решения
// по сути дела проверятся Ваши: базовые знания + способность изменить решение в свете новых требований
2. Что будет происходить?
- в период 15июня-15сентября Вы работаете в харьковском офисе EPAM на full-time на боевом проекте под моим руководством
- получаете на время обучения зп - 250$
- слушаете и применяете теор материал, который я Вам начитываю: Spring Core, Spring MVC, Hibernate, RDBMS fundamentals, web-app fundamentals.
- по окончанию срока обучения (15 сентября) Вы сдаете экзамен
- по результатам экзамена (15 сентября) Вы либо отчисляетесь, либо я передаю Вас на другие проекты в другие команды с переходом в статус Junior Java Developer (D1)
- в зависимости от результатов экзамена Вы получаете повышение зп
3. Что Вы с этого будете иметь?
- гарантированную зп на время обучения
- фундаментальные знания от System Architect
- опыт работы в реальном проекте с реальным стеком технологий (JSF+Spring+Hibernate+Oracle)
- возможность продолжить работу в одной из крупнейших IT компаний
P.S. Если у Вас есть знакомые заинтересованные в быстром старте в карьере в IT - передайте новость им.
1. Как попасть?
- прислать мне на Golovach.Ivan@gmail.com резюме (главное: Ваш уровень английского, что писали/изучали в институте)
- выполнить ряд заданий (на написание нескольких сот строк кода на Java), которые я вышлю в ответ на резюме
- выслушать мои замечания на выполненные задания и исправить решения
// по сути дела проверятся Ваши: базовые знания + способность изменить решение в свете новых требований
2. Что будет происходить?
- в период 15июня-15сентября Вы работаете в харьковском офисе EPAM на full-time на боевом проекте под моим руководством
- получаете на время обучения зп - 250$
- слушаете и применяете теор материал, который я Вам начитываю: Spring Core, Spring MVC, Hibernate, RDBMS fundamentals, web-app fundamentals.
- по окончанию срока обучения (15 сентября) Вы сдаете экзамен
- по результатам экзамена (15 сентября) Вы либо отчисляетесь, либо я передаю Вас на другие проекты в другие команды с переходом в статус Junior Java Developer (D1)
- в зависимости от результатов экзамена Вы получаете повышение зп
3. Что Вы с этого будете иметь?
- гарантированную зп на время обучения
- фундаментальные знания от System Architect
- опыт работы в реальном проекте с реальным стеком технологий (JSF+Spring+Hibernate+Oracle)
- возможность продолжить работу в одной из крупнейших IT компаний
P.S. Если у Вас есть знакомые заинтересованные в быстром старте в карьере в IT - передайте новость им.
Получил четвертую звезду!
Всем привет.
Я с 11 апреля работаю в харьковском офисе EPAM на должности Lab Lead в звании System Architect (D4).
Я с 11 апреля работаю в харьковском офисе EPAM на должности Lab Lead в звании System Architect (D4).
четверг, 21 апреля 2011 г.
Intel® Threading Building Blocks – Documentation
Intel® Threading Building Blocks – Documentation::
- Release Notes [TXT 6KB]
- Getting Started Guide [PDF 122KB]
- Tutorial [PDF 573KB]
- Reference Manual [PDF 1.1MB]
- Design Patterns [PDF 264KB]
- Release Notes [TXT 6KB]
- Getting Started Guide [PDF 122KB]
- Tutorial [PDF 573KB]
- Reference Manual [PDF 1.1MB]
- Design Patterns [PDF 264KB]
пятница, 1 апреля 2011 г.
checkdeadlock.org - первый релиз
В продолжении к предыдущему посту. Т.к. домашний компьютер постоянно включенным оказалось очень неудобно, разместил на hosting.ua проект checkdeadlock.org. На этом хостинге нет контейнера сервлетов, поэтому пришлось написать свой небольшой сервер, который работает на 8080 порту (т.к. я не root, то доступ к 80 мне пока закрыт. Нужно будет поговорить по этому поводу с саппортом. Но пока и так неплохо).
суббота, 26 марта 2011 г.
Нахождение взаимных блокировок потоков при статическом анализе кода
Всем доброго вечера.
Когда Иван читал у нас, на мех-мате в Каразина свой спецкурс у меня появилась навящевая идея по поиску дедлоков без запуска программы, только на основании ее кода. Было сделано несколько попыток найти какой-то внятный алгоритм. К настоящему моменту я достаточно неплохо, как мне кажется, продвинулся в этом направлении.
Чтобы не усложнять до предела работу по парсингу кода на Java или C я написал простой язык для описания потоков.
Когда Иван читал у нас, на мех-мате в Каразина свой спецкурс у меня появилась навящевая идея по поиску дедлоков без запуска программы, только на основании ее кода. Было сделано несколько попыток найти какой-то внятный алгоритм. К настоящему моменту я достаточно неплохо, как мне кажется, продвинулся в этом направлении.
Чтобы не усложнять до предела работу по парсингу кода на Java или C я написал простой язык для описания потоков.
среда, 16 марта 2011 г.
среда, 9 марта 2011 г.
вторник, 8 марта 2011 г.
habrahabr: Обзор NoSQL систем
Обзор NoSQL систем
Cassandra, HBase, Riak, Scalaris, Voldemort, CouchDB, MongoDB, Neo4j, Redis, Tokyo Cabinet
Cassandra, HBase, Riak, Scalaris, Voldemort, CouchDB, MongoDB, Neo4j, Redis, Tokyo Cabinet
понедельник, 7 марта 2011 г.
A Note on Distributed Computing
A Note on Distributed Computing
Abstract
We argue that objects that interact in a distributed system need to be dealt with in ways that are intrinsically different from objects that interact in a single address space. These differences are required because distributed systems require that the programmer be aware of latency, have a different model of memory access, and take into account issues of concurrency and partial failure.
We look at a number of distributed systems that have attempted to paper over the distinction between local and remote objects, and show that such systems fail to support basic requirements of robustness and reliability. These failures have been masked in the past by the small size of the distributed systems that have been built. In the enterprise-wide distributed systems foreseen in the near future, however, such a masking will be impossible.
We conclude by discussing what is required of both systems-level and application level programmers and designers if one is to take distribution seriously.
Abstract
We argue that objects that interact in a distributed system need to be dealt with in ways that are intrinsically different from objects that interact in a single address space. These differences are required because distributed systems require that the programmer be aware of latency, have a different model of memory access, and take into account issues of concurrency and partial failure.
We look at a number of distributed systems that have attempted to paper over the distinction between local and remote objects, and show that such systems fail to support basic requirements of robustness and reliability. These failures have been masked in the past by the small size of the distributed systems that have been built. In the enterprise-wide distributed systems foreseen in the near future, however, such a masking will be impossible.
We conclude by discussing what is required of both systems-level and application level programmers and designers if one is to take distribution seriously.
Oracle Coherence: author blog
Обнаружен блог Cameron Purdy.
Cameron Purdy was the founder and president of Tangosol, Inc, a market leader in delivering in-memory caching and data management solutions to companies building and running mission critical enterprise J2EE applications. He currently is VP of Development at Oracle.
P.S. Tangosol разработал Coherence, был куплен Ораклом за 200М.
P.P.S. Cameron Purdy on Scaling Out Data Grids.
Cameron Purdy was the founder and president of Tangosol, Inc, a market leader in delivering in-memory caching and data management solutions to companies building and running mission critical enterprise J2EE applications. He currently is VP of Development at Oracle.
P.S. Tangosol разработал Coherence, был куплен Ораклом за 200М.
P.P.S. Cameron Purdy on Scaling Out Data Grids.
среда, 2 марта 2011 г.
Deep-deep-deep Google internals: Chubby
1. "The Chubby Lock Service for Loosely-Coupled Distributed Systems"
Mike Burrows, Google Inc.
Abstract
We describe our experiences with the Chubby lock service, which is intended to provide coarse-grained locking as well as reliable (though low-volume) storage for a loosely-coupled distributed system. Chubby provides an interface much like a distributed file system with advisory locks, but the design emphasis is on availability and reliability, as opposed to high performance. Many instances of the service have been used for over a year, with several of them each handling a few tens of thousands of clients concurrently. The paper describes the initial design and expected use, compares it with actual use, and explains how the design had to be modified to accommodate the differences.
OSDI'06: Seventh Symposium on Operating System Design and Implementation, Seattle, WA, November, 2006.
"We expected Chubby to help developers deal with coarse-grained synchronization within their systems, and in particular to deal with the problem of electing a leader from among a set of otherwise equivalent servers. For example, the Google File System [7] uses a Chubby lock to appoint a GFS master server, and Bigtable [3] uses Chubby in several ways: to elect a master, to allow the master to discover the servers it controls, and to permit clients to find the master. In addition, both GFS and Bigtable use Chubby as a well-known and available location to store a small amount of meta-data; in effect they use Chubby as the root of their distributed data structures. Some services use locks to partition work (at a coarse grain) between several servers."
-------------
"Paxos Made Live - An Engineering Perspective"
Paxos Made Live - An Engineering Perspective
Tushar Chandra
Robert Griesemer
Joshua Redstone
June 20, 2007
Abstract
We describe our experience in building a fault-tolerant data-base using the Paxos consensus algorithm. Despite the existing literature in the field, building such a database proved to be non-trivial. We describe selected algorithmic and engineering problems encountered, and the solutions we found for them. Our measurements indicate that we have built a competitive system.
Mike Burrows, Google Inc.
Abstract
We describe our experiences with the Chubby lock service, which is intended to provide coarse-grained locking as well as reliable (though low-volume) storage for a loosely-coupled distributed system. Chubby provides an interface much like a distributed file system with advisory locks, but the design emphasis is on availability and reliability, as opposed to high performance. Many instances of the service have been used for over a year, with several of them each handling a few tens of thousands of clients concurrently. The paper describes the initial design and expected use, compares it with actual use, and explains how the design had to be modified to accommodate the differences.
OSDI'06: Seventh Symposium on Operating System Design and Implementation, Seattle, WA, November, 2006.
"We expected Chubby to help developers deal with coarse-grained synchronization within their systems, and in particular to deal with the problem of electing a leader from among a set of otherwise equivalent servers. For example, the Google File System [7] uses a Chubby lock to appoint a GFS master server, and Bigtable [3] uses Chubby in several ways: to elect a master, to allow the master to discover the servers it controls, and to permit clients to find the master. In addition, both GFS and Bigtable use Chubby as a well-known and available location to store a small amount of meta-data; in effect they use Chubby as the root of their distributed data structures. Some services use locks to partition work (at a coarse grain) between several servers."
-------------
"Paxos Made Live - An Engineering Perspective"
Paxos Made Live - An Engineering Perspective
Tushar Chandra
Robert Griesemer
Joshua Redstone
June 20, 2007
Abstract
We describe our experience in building a fault-tolerant data-base using the Paxos consensus algorithm. Despite the existing literature in the field, building such a database proved to be non-trivial. We describe selected algorithmic and engineering problems encountered, and the solutions we found for them. Our measurements indicate that we have built a competitive system.
вторник, 1 марта 2011 г.
Ищу работу
Добрый день.
Я подумываю о смене работы.
Ищу пописать какую-нибудь низкоуровневую распределенную инфраструктуру на основе Netty/JGroups/etc.
Или сервер многопоточный какой.
Или распределенной хранилище данных.
Или инфраструктуру для MMOGame.
Или поюзать какую-нибудь низкоуровневую распределенную инфраструктуру: Cassandra, HBase, HDFS, Hadoop, PIG, etc
Бизнес-проекты на {GWT,JSF}/{Spring, EJB}/Hibernate/RDBMS пока не рассматриваю.
Рассмотрю любой город бСССР и любой режим работы.
Могу менторить юниоров.
К "печенькам" не требователен.
P.S. Golovach.Ivan@gmail.com
P.P.S. На письма вида "высылайте резюме, а потом мы вам как-нибудь расскажем про проект" не отвечу.
Я подумываю о смене работы.
Ищу пописать какую-нибудь низкоуровневую распределенную инфраструктуру на основе Netty/JGroups/etc.
Или сервер многопоточный какой.
Или распределенной хранилище данных.
Или инфраструктуру для MMOGame.
Или поюзать какую-нибудь низкоуровневую распределенную инфраструктуру: Cassandra, HBase, HDFS, Hadoop, PIG, etc
Бизнес-проекты на {GWT,JSF}/{Spring, EJB}/Hibernate/RDBMS пока не рассматриваю.
Рассмотрю любой город бСССР и любой режим работы.
Могу менторить юниоров.
К "печенькам" не требователен.
P.S. Golovach.Ivan@gmail.com
P.P.S. На письма вида "высылайте резюме, а потом мы вам как-нибудь расскажем про проект" не отвечу.
суббота, 19 февраля 2011 г.
Почему я заинтересовался IMDG.
Десятилетие 2005-2015 - это десятилетие (в том числе) The Concurrency Revolution.
Но текущая ситуация такова, что ядра то лепят (уже десятками), ноды объединяют в кластеры (уже сотнями), а новых подходов все нет.
Threads, Actors - это не выход: 1) слишком низкоуровнево, 2) количество сущностей thread/actor должно расти с колвом ядер.
Fork/Join как попытка уйти от явного указания кол-ва потоков - применима если мы сами параллелим задачу. Колво потоков задает framework, но правило разбиения задачи - задаем мы.
Моя идея такова, что чем более масштабируема система/задача, тем более слабой моделью памати она обладает. На уровне процессора(x86 mem model) или языка (New Java Mem Model) модель памяти уже задана, и мы можем только спорить - хорошо ли приспособлена Java для 100K потоков, или тут уже нужен Erlang.
Но если мы сами создаем Модель Памяти? Скажем берем realiable multicasting, на нем строим другие мулькастинги (atomic, causal, total order, etc), на них строим любые модели Shared Memory, поверх Shared Memory реализуем какой-нибудь механизм координации - что-то вроди Linda. Это текущие процессы.
А если так: business people пишут свою логику, а система по логике 1) находит слабейшую можель памяти на которой это еще будет работать, 2) указывает, какие моменты в бизнесс-правилах наиболее органичивают систему в масштабировании. Под эту модель памяти поднимается Grid. Т.е. масштабируемость системы зависит исключительно от бизнесс-логики, а не от того какой кэш вы выбрали: GemFire ReplicatedCache или Coherence PartitionedCache.
P.S. В моем представлении, сейчас период безвременья между Февральской и Октябрьскими Революциями. Царя уже свергли (ядра лепят, кластеры поднимают), но нет мощной идеи определяющей развитие на десятилетие вперед (конституционная монархия, либеральная демократия, мировая революция == Shared Memory, MOM, Linda, IMDG, Actors, ...).
P.P.S. Естественно государственный деятель должен учитывать вызовы будущего - мировые войны, модернизацию промышленности, решение проблем урбанизации (я имею в виду квантовые компьютеры с миллионами/миллиардами "потоков" между которыми очень-очень странные и асимметричные взаимодействия).
Но текущая ситуация такова, что ядра то лепят (уже десятками), ноды объединяют в кластеры (уже сотнями), а новых подходов все нет.
Threads, Actors - это не выход: 1) слишком низкоуровнево, 2) количество сущностей thread/actor должно расти с колвом ядер.
Fork/Join как попытка уйти от явного указания кол-ва потоков - применима если мы сами параллелим задачу. Колво потоков задает framework, но правило разбиения задачи - задаем мы.
Моя идея такова, что чем более масштабируема система/задача, тем более слабой моделью памати она обладает. На уровне процессора(x86 mem model) или языка (New Java Mem Model) модель памяти уже задана, и мы можем только спорить - хорошо ли приспособлена Java для 100K потоков, или тут уже нужен Erlang.
Но если мы сами создаем Модель Памяти? Скажем берем realiable multicasting, на нем строим другие мулькастинги (atomic, causal, total order, etc), на них строим любые модели Shared Memory, поверх Shared Memory реализуем какой-нибудь механизм координации - что-то вроди Linda. Это текущие процессы.
А если так: business people пишут свою логику, а система по логике 1) находит слабейшую можель памяти на которой это еще будет работать, 2) указывает, какие моменты в бизнесс-правилах наиболее органичивают систему в масштабировании. Под эту модель памяти поднимается Grid. Т.е. масштабируемость системы зависит исключительно от бизнесс-логики, а не от того какой кэш вы выбрали: GemFire ReplicatedCache или Coherence PartitionedCache.
P.S. В моем представлении, сейчас период безвременья между Февральской и Октябрьскими Революциями. Царя уже свергли (ядра лепят, кластеры поднимают), но нет мощной идеи определяющей развитие на десятилетие вперед (конституционная монархия, либеральная демократия, мировая революция == Shared Memory, MOM, Linda, IMDG, Actors, ...).
P.P.S. Естественно государственный деятель должен учитывать вызовы будущего - мировые войны, модернизацию промышленности, решение проблем урбанизации (я имею в виду квантовые компьютеры с миллионами/миллиардами "потоков" между которыми очень-очень странные и асимметричные взаимодействия).
Подписаться на:
Сообщения (Atom)