Сучасна диджитал-освіта для дітей — безоплатне заняття в GoITeens ×
Mazda CX 5
×
SSE в Just Techologies AS
  • java-программирование сегодня

    @qwerty_smerty, скажите, а Вы по-русски читаете? хотя бы те вещи, которые пишут непостредственно Вам?
    волею судеб я могу положительно ответить на Ваш вопрос здесь таки занимаются вопросами искусственного интеллекта. совместно с университетом Ювяскеля. чтобы понять, что там этим действительно занимются, забейте в Гугл «Терзиян Ваган Яковлевич» и почитайте материалы.
    теперь начнем походить к сути. ИИ — на текущий момент чистая наука, широкого коммерческого применения которой до сих пор нет. что в итоге? в итоге и здесь, и там — это сфера чистого научного знания, которым занимаются университеты. и это хорошо., но шансов у среднего программиста там, и у среднего программиста здесь попасть в такой проект примерно поровну. и примерно поровну шансов, что он будет приносить деньги.
    и уже совсем по сути: Вам, как и многим другим нашим коллегам, кажется что как только Вы попадете на благословенную землю страны Тамландии, то Вы непременно будете участвовать в создании ИИ, программировании роботов, создании всяческих 3D движков и прочих наукоемких проектах. реальность несколько другая. плотность наукоемких проектов в мире вообще крайне низка. большинство из них разрабатывается под крыло минобороны или государственных грантов. это значит, что мои или Ваши шансы попасть в такие проекты резко стремятся к нулю. Вы не забыли, надеюсь, что холодная война закончилась всего 20 лет назад? что же касается широкого спектра in house проектов, это это проекты в первую очередь очень денежные и очень отвественные — банки, страховые компании, телекомы. и нет более консервативного бизнесса нежели банковский, иными словами большинство проектов в Тамландии — legacy. причем такое дремучее легаси, которое мало кто видел здесь. и это нужно очень бережно и очень внимательно поддерживать, никаких рефакторингов, аджайлов и прочего, цена ошибки — миллионы и миллиарды.
    есть крупные разработчики типа Google, MS, Oracle, Sun. и у них тоже есть продукты, которые нужно поддерживать. конечно доказав свою пригодность, лояльность и имея добрую толику удачи можно добится участия в революционных разработка. в Тамландии на это уходит 10−15 лет работы где-то по 10−16 часов в среднем. там так принято.
    так что, как я и говорил выше, дарзанебы.

    p.s. и да, злая часть банковского легаси — это EJB 2.0 на WebShere 4.x. в 90е очень хорошо продавалось J2EE.

  • java-программирование сегодня

    @qwerty_smerty, вот не надо этого. Вы сначала узнайте, как оно там, а потом сравнивайте. будете удивлины еще больше.
    и тут бы мне закончить, но поскольку сегодня я добр, я раскрою мысль: во всех проектах моими коллегами были люди оттуда — австрийцы, англичане, датчане и множество американцев. и это были не менеджеры, технические директора и сэйлз — это были программисты, тим-лиды, QA. и архитектура, и рефакторинг делались больше здесь, нежели там. и эти проекты работают в рельном бизнессе, ими пользуются реальные люди.

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

  • java-программирование сегодня

    1) распределенная по всему миру система подбора персонала. от регистрации человека, до отслеживания его карьерной истории и сопровождения в идеале всю карьеру. включает в себя много всякого, включая псевдоязык вокруг которого вращается примитивный делфи-образный UI, позволяющий пользователями ингерировать в приложение свои собственные формы. (J2EE, J2SE, Swing)
    2) портальное решение для хранения статистической информации, ее представления, экспорта из внешних источников и модификации (J2SE, Spring, Liferay Portal)
    вот таки два проекта, в которых я участвовал (ю) на текущем месте работы. на предыдущих — два портала на базе Liferay — биллинг (J2EE) — псевдопортаное, псевдокастомизационное решение выросшее из сайта (J2SE, Servlets) — система регистрации и учета доменных имен (J2SE, Servlets) — бизнесс-логика виртуального казино (J2EE) — опять таки биллинговая система (J2EE + JNI)

    это те проекты, в которых я принимал более или менее деятельное участие за последние 8 лет. не покидая пределов родного Харькова

  • Потенциальные трудности с СПД

    Knoxville, оформить действительно не сложно, закрыть — на порядок сложнее, но вполне возможно. что касается закрытия СПД, то закрывать его не обязательно, можно просто подавать в налоговую отчеты с нулевым доходом или даже договорить о приостановлении деятельности.
    в работе по форме СПД есть следующие большие минусы, которые нужно учитывать
    1) Вы не являетесь штатным сотрудником. на Вас не распространяются блага, описанные в КЗоТ и работодатель не страхует никаких Ваших рисков, как то пиратское ПО, биржа труда, налоговая инспекция и т.п.
    2) поскольку Вы не являетесь штатным сотрудником, то расторгнуть с Вами договорные отношения можно в один день, без объяснения причин и каких-либо выплат
    3) по сей день деятельность СПД регулируется только Указом Президента, разрешающим работу по ЕН, больше никакой правовой базы не существует. это чревато в первую очередь тем, что во время, которое проходит после «сдачи работ» до подписания акта примеки-сдачи выполненных работы, Вам официально никто ничего не должен. иначе говоря, если Вам обещали зарплату 5го числа и ее нет вовремя, то, в случае, если акт не подписан, потребовать Вы ничего не можете
    4) никто не должен Вам никаких оплачивамых отпусков и больничных
    5) Вы сами должны вести свою бухгалтерию, пусть она и примитивна, но занимает некоторое количесво времени
    теперь о плюсах
    1) Вы не являетесь штатным сотрудником. никаких 2х недель отработки, записей в трудовой, увольнений по статье. Вы сами распоряжатесь своими финансами, сами решаете сколько платить в ПФ
    2) поскольку Вы не являетесь штатным сотрудником, то никакие расписания и прочия правила для сотрудников, на Вас не распространяются. более того, при малейшем недовольстве местом работы, Вы можете собрать вещи и уйти. даже не ставя никого в известность.
    3) Вы получаете «белый» доход, иначе говоря фиксируете полностью всю сумму, которую получаете. и, в случае наличия актов приемки-сдачи выполненных работ, можете потребовать всю сумму в судебном порядке. что существенно отличает Вас от штатного сотрудника, получающего «черным» налом.
    4) Вы получаете возможность работать напрямую с нерезидентами Украины и получать доход в валюте. которую сами вольны продавать, когда захотите
    5) Вы сами можете вести свою бухгалтерию, иначе говоря контролировать свои доходы и расходы непосредственно. есть возможность поручить это третьему лицу, буде таковое найдется

    итого, есть свои достоинства и недостатки, как и везде. каждый выбирает сам, что ему милее КЗоТ с отпусками и больничными, или СПД с его относительной свободой. кстати про стаж, на СПД стаж работы по специальности идет в соответствии с родом деятельности СПД. если кто-то утверждает обратное, он либо лжет, либо сам введен в заблуждение.

  • Швеция — жизнь и работа

    2Denix, а, простите, о ком еще Вы думаете? О соседях? А Вам не кажется, что это как-то... не прилично? И чтобы не писать особо информативных постов, если не кажется, то почему?

  • Швеция — жизнь и работа

    2Denix, а почему?

  • Швеция — жизнь и работа

    2Denix, я прошу прощения, что встреваю в такую высокоинтеллекутальную дискуссию, но скажите, а вот Вам лично не все-равно, как живут Ваши соседи? С кем спят, от кого рожают детей? Автор, на которого Вы ссылаетесь, носит в голове красивый букет комплексов made in USSR, радостно, что в Шведции этих комплексов нет.

    И я не совсем понял, если Вас не затруднит поясните мне убогому, чем данный конкретный аспект опасен для девушек?

  • Квартирный вопрос

    и я присоеденеяюсь к eugene_n, но я хочу не в областном центре, хотя в этойже стране. есть под Коктебелем один поселок, буквально при въезде в Кокт, но еще за последним холмом. какие там степи... вот это место, где бы я хотел умереть. кто знает, может получится, лет 30 еще Бог даст поживем:)

  • Конфигурация вашего рабочего места?

    на новом рабочем месте пока Core2 Duo 2, 24 + 2Gb RAM + 250Gb HDD. WinXP SP3. один 17″ Samsung, по минимуму хватает, хотя конечно хочется больше дюймов и желательно два. стол, кресло, кофе-машина — все хорошо. балкончик, где можно покурить не спускаясь на первый этаж, тоже хорошо.
    дома Core2 Duo 3.0 + 3Gb RAM + 4×350 GB RAID 1.0. один ViewSonic P227f 22″ CRT. WinXP SP3. стол нужно поменять ибо мелок, а большое кожанное кресло давече потеряло ногу. будем посмотреть.
    ноут LG P100 15, 4″ Core2 Duo 1, 67 + 2Gb RAM + 80Gb HDD, wifi и прочие bluetooth. Ubuntu Linux 8.10

    если говорить о мечтах, то очень хочу новый ноут Apple MacBook Pro, куплю как только заработаю на него, независимо от кризиса:)

  • SandBox (IT club in Kiev)

    я бы с удовольствием, но Киев от меня на расстоянии ~600 км:)

  • Развитие ресурса — статьи о Java и не только

    2Сергей Волошин, с новыми и неизвестными технологиями получается замкнутый круг. Аутсорсер-заказчик в 80% против, и я его понимаю — он не хочет инвестировать в чистый рисерч, он не хочет за свой счет повышать квалификацию сабконтрактеров. Заказчик хочет продукт, заказчик хочет продукт дешево, иначе бы он его разрабатывал дома. Так что заказы на новые и не известные технологии редки. С другой стороны невозможно приоткрыть завесу тайны над новй и не известной технологией, не разобравшись с ней, не используя в боевом проекте, чтобы посмотреть что эта технология может, чего не может, как у нее плюсы, какие минусы.
    С удовольствием почитаю о GWT, что касается сборочных систем, то опять-таки Ant и Мaven2 удивительно просты в использовании. И там достаточно мануала. Доработка первого — это сама по себе джедайская практика, а второго — примерно также проста, как и использование. С другой стороны я за 8 лет работы написал всего один плагин для Maven2. В остальном хватает стандартных.

    Я собственно к чему все начал-то:), проблема не в том, что Java-разработчики мечтают превратиться в закрытый клуб, гильдию и запечатывать знания в сундуки. Просто одним из плюсов Java лично для меня 10 лет назад стало именно то, что она просто, понятно и прозрачно документирована. Единственным полем для документирования является тот факт, что не все документированное работает, а кое-что работает не так, как описано, или начинает работать, как описано, после несколько танцев с бубном и камланий.:) Вот про па танцев, модель бубна и благовония для камланий можно и дОлжно писать.

  • Развитие ресурса — статьи о Java и не только

    джентельмены, как потенциальный автор статей по Java (не считая себя гиперпрофессионалом), позволю себе вставить свои пару центов.
    самым главным вопросом для меня как был, так и остается один —, а о чем собственно писать? Java довольно стара, как технология, о ней уже написана не одна и не две статьи, обзора, форума, спецификации. единственным вкладом в комьюинити я вижу джедайские технологии по «сращиванию» каких-то фрэймворков. например давече я пытался интегрировать JPOX и Spring, положительного результата я пока не достиг. хотя официально именно JPOX приводиться в качестве примера интеграции Spring и JDO. вот об этом, буде у меня время продолжить эксперименты, я бы написал с удовольствием. расшифровывать термины JPOX, Spring, EJB — это бессмысленно на мой взгляд, достаточно взять книгу по соотвествующему фрэймворку уже переведенную.
    еще один момент, мало кто из Java-разработчиков работает со Streamline технологиями, так уж повелось, что огромная часть аутсорсинга — это легаси., а там ничего нового нет, к чему говорить о том, что уже не раз и не два описано людьми, которые гораздо более сведущи в написанни статей и делают на этом деньги.

    и последнее, в планете я встечал пару довольно толковых постов. возможно имеет смысл связываться с авторами и делать авторскую «агрегацию» коротких заметок? коль скоро нет длинных?

  • Какие плюсы дает степень к.т.н. в программисткой фирме?

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

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

  • Какие плюсы дает степень к.т.н. в программисткой фирме?

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

    так что ответ — да, 2, 5к в Киеве, уважаемый billneutron, для Вас возможны. возможны и в Харькове, но с меньшей вероятностью — тут это средне-потолочная зарплата сеньйора. насколько легко будет получить такой доход? я не знаю. с другой стороны, а Вам зачем в Киев или Харьков, если у Вас в Черкасах все так прекрасно? я бы не ехал, наборот, я вот подумываю, а не начать ли готовить себе переезд в город, где за $70k можно купить хорошую квартиру в новострое. у нас — минимум вдвое дороже.:)

  • О качестве кода и профессионализме

    2Андрей Фесуненко, в данном конкретном случае существует два и более мнения о том, что есть код, и что считать качественным кодом. если говорить с позиции бизнеса, целей и задач производства — то Вы безусловно правы. однако, с точки зрения бизнеса код есть абстракция, он не есть конечной целью и даже средством является опосредованно. целью есть получение бОльшей прибыли от автоматизации каких-то бизнесс-процессов, средством — программный продукт. код, с точки зрения бизнеса, есть неизбежное зло, и он просто должен быть и просто должен работать. иерархически, чем выше уровень абстракции субъекта, тем меньше требований непосредственно к коду, и больше к бизнес-задачам.

    таким образом, я считаю корректным в данном случае говорить о коде на уровне абстракции Developer -> Senior Developer -> Tech Lean -> Architect, иначе говоря инженерных специалистов, которым важно, что бы продукт не только работал, но был прост в поддержке и улулчшении. задачи соотвествия продукта требованиям, ожиданиям и бюжетам заказчика решаются на уровне Project Manager -> Business Analyst -> QA -> Customer.

  • О качестве кода и профессионализме

    2Щетинин Сергей, хм, интересная идея, спасибо. попробую на практике, вобщем-то привентивное тестирование архитектуры в любом случае не будет вредным.,

    а моя манера мне самом напоминает такой себе микро-Agile — сначал появляется воплощение идеи, прототип. затем он тестируется в использовании на работоспособность. потом добаляются логи — я обожаю дебагер, но не люблю гонять программу в дебагере долго, поэтому предпочитаю локализовывать ошибки логами. потом проверяем отказоустойчивость. и наконец документируем. не претендую на авторство универсального концепта, но если интересно — попробуйте, может быть удастся что-то оптимизировать или упорядочить:)

  • О качестве кода и профессионализме

    2Щетинин Сергей, ну серебрянных пуль в нашей индустрии еще не отлили ни по одному вопросу. так что универсальных рецептов нет и врядли появятся. опять-таки здравый смысл рулит. я сам пишу код итеративно — сначала сам код; потом юнит-тесты потока success; потом добавляю в код логи, много логов, хотя сейчас хочу попробовать заменить эту стадию использование АОП; потом юнит-тесты потоков exception/error; потом документацию к API. собственно после этого считаю, что функционал готов. если мне приходится менять логику, я вместе с логикой класса меняю и API документацию. мне так удобно, уж не знаю правильно я делаю или нет.:)

    p.s. насчет юнит-тестов все знаю, но не могу никак понять, как можно писать тесты к тому, чего еще нет:) по этому поводу буду рад совету:)

  • О качестве кода и профессионализме

    2Щетинин Сергей, в любом случае то, что мы называем «качественный код» есть компромис между временными затратами и полученным результатом. что касается документации, то она может быть разделена на две категории:

    1. документирование API, пишется программистами и изменяется вместе с кодом. на это уходит не так много времени, если делать все одномоментно. тоже справедливо для юнит-тестов. и эти же процессы занимают колоссальное количество времени, если делать их постфактум.
    2. guides, help, возможно финальные диаграммы классов. кроме диаграмм классов пишется техническим писателем в соавторсвте с программистами после завершения итерации. разумеется эта работа должна быть оплачена заказчиком.
  • О качестве кода и профессионализме

    стандарты качества на самом деле одинаковы для всех. если соглашения по написанию кода описанные в стандартных Code Conventions, эти соглашения можно слегка модфицировать на уровне конторы (для Java я все-таки предпочитаю 4 проблема в табуляции вместо 8 и 120 символов в строке вместо 80). все остальное — Camel-style notation, понятные имена классов и переменных, JavaDocs — не изменяются ни за что и никогда. даже если заказчик явно не требует такого кода, он всегда рад такой код видеть. более того, это однозначно полезно для проекта в целом, для команды вообще. юнит-тесты и обработка исключений полезны для проекта почти всегда (единственным известным мне исключением является софт для мобильных дейвайсов, где ручное тестирование по соотношению цена/качество значительно эффективнее эмуляции всех сред для юнит-тестов, хотя наверное и тут возможны варианты). и опять таки, даже если заказчик этого не требует, то имеет смысл это делать, проект без базы юнит-тестов мегадорог в поддержке, это случай из моей практики.

    1. да, команда должна стремиться писать качественный код
    2. да, я определенно уверен, что хороший код лучше плохого. хотя бы только потому, что а) плохой код очень не понятен, а следовательно его тяжело поддерживать и улучшать; б) очень часто внутри плохого кода кроются ошибки дизайна, влияющие на стабильность и производительность приложения и эти ошибки очень тяжело выявлять.
    3. самый простой способ выяснить, окупятся ли дальнейшие улучшения кода — peer review. если новому человеку, знающему язык, понятна структура, назначение и алгоритм, если новый человек-эксперт не нашел при review откровенных lack of desing, то можно на этом этапе остановиться. хотя если такового человека нет, то сильно помогают наборы метрик, которые можно сбаллансированно настроить.
    4. любые стандартны всегда определяются с точки зрения common sence. в идеале — это экспертная группа, которая вырабатывает правила написания кода, действующие в компании по-умолчанию. чаще всего — начинает кто-то один, остальные обсуждают и дополняют. если заказчик не предлагает своих метрик — действуют конторские или командные, если речь идет о команде контракторов-удаленщиков.
    5. профессионал — тот кто пишет качественный код. т.е. код соотвествующий на 75−90% публичным Code Conventios. безусловно, качество кода напрямую связанно с профессионализмом и квалификацией разработчика. иначе говоря, если человек высокопрофессионален, он пишет качествнный код. обратное НЕ верно. это лишь один из параметров, который отличает профессионала он не профессионала.
  • Посоветуйте классную ИТ-компанию!

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

    2NiCketT, есть еще Luxsoft киевский, есть Днепровский., а что до десктоп-приложений или чего-то подобного — ну есть Genlteware у нас в Харькове., но тут я не уверен насчет релокации для джуниора. у нас есть десктоп-проект, но там не нужны джуниоры и точно не будет релокации., а если говорить общО, то Вы работу ищите или место, где Вам будет максимально комфортно? если последнее — нет ничего лучше, чем собственный стартап. сами решите, чем будете заниматься, а чем нет:)

← Сtrl 1... 333435363738 Ctrl →