Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 72
Идею приложения должен подавать сторонний человек, который не участвует в конкурсе. Иначе может получиться код совсем разного качества, просто потому что у одного человека могут быть наработки, у другого нет.
Репозиторий должен быть открытым (предлагаю github). Было бы здорово шарить скрины. Затем уже посмотрев на код друг-друга и обсудив можно выступить с рассказом о том, в чем разница между выбранными технологиями и так далее.
Опять же, я не вижу смысла в бенчмарках, поскольку у всех свои требования к производительности. Для большинства выбор в пользу технологии идет по совсем другим причинам. Единственный реальный бенчмарк — удобство и производительность программиста. Одна технология может проиграть другой, только если на общих задачах будут возникать постоянные проблемы.
Репозиторий должен быть открытым (предлагаю github). Было бы здорово шарить скрины. Затем уже посмотрев на код друг-друга и обсудив можно выступить с рассказом о том, в чем разница между выбранными технологиями и так далее.
Опять же, я не вижу смысла в бенчмарках, поскольку у всех свои требования к производительности. Для большинства выбор в пользу технологии идет по совсем другим причинам. Единственный реальный бенчмарк — удобство и производительность программиста. Одна технология может проиграть другой, только если на общих задачах будут возникать постоянные проблемы.
>Идею приложения должен подавать сторонний человек, который не участвует в конкурсе. Иначе может получиться код совсем разного качества, просто потому что у одного человека могут быть наработки, у другого нет.
спорный аргумент, ибо готовые наработки — тоже плюс фреймворка. лично мне — всё равно.
>Репозиторий должен быть открытым (предлагаю github).
боюсь, что не я один git пока неосилил.
>Было бы здорово шарить скрины.
ээ… не понял — приложение ж дома будет писаться…
>Для большинства выбор в пользу технологии идет по совсем другим причинам.
да, возможно, ну нужно ж ведь показать все сильные/слабые стороны.
спорный аргумент, ибо готовые наработки — тоже плюс фреймворка. лично мне — всё равно.
>Репозиторий должен быть открытым (предлагаю github).
боюсь, что не я один git пока неосилил.
>Было бы здорово шарить скрины.
ээ… не понял — приложение ж дома будет писаться…
>Для большинства выбор в пользу технологии идет по совсем другим причинам.
да, возможно, ну нужно ж ведь показать все сильные/слабые стороны.
Готовые наработки, твои, личные далеко не плюс фреймворка, это плюс тебя :)
Там нет ничего сложного, я готов помочь, но можно и google code заюзать
Ну а в чем проблема screen из дома расшарить?
Сильная сторона чего? Если я влеплю memcached в приложение и на тестах оно надерет всем зад, это сильная сторона фреймворка? Возможно это мои личные заморочки, но тема оптимизации под высокие нагрузки кажется мне востребованной, когда об этих высоких нагрузках приходится задумываться, и выходит далеко за рамки написать приложение за 12 часов. Если очень хочется в последствии можно будет взят эти примеры и показать как здорово масштабируются Рельсы\Грельсы\Джанга, но это пожалуй и отдельные часы и отдельная тема (интересное кстати продолжение идеи :). Сравнение же голых приложений кажется мне надуманным сильно. Ну потешет себя один из участников что его приложение работает в 20 раз быстрее в вакууме, реальность это врятли отразит.
Там нет ничего сложного, я готов помочь, но можно и google code заюзать
Ну а в чем проблема screen из дома расшарить?
Сильная сторона чего? Если я влеплю memcached в приложение и на тестах оно надерет всем зад, это сильная сторона фреймворка? Возможно это мои личные заморочки, но тема оптимизации под высокие нагрузки кажется мне востребованной, когда об этих высоких нагрузках приходится задумываться, и выходит далеко за рамки написать приложение за 12 часов. Если очень хочется в последствии можно будет взят эти примеры и показать как здорово масштабируются Рельсы\Грельсы\Джанга, но это пожалуй и отдельные часы и отдельная тема (интересное кстати продолжение идеи :). Сравнение же голых приложений кажется мне надуманным сильно. Ну потешет себя один из участников что его приложение работает в 20 раз быстрее в вакууме, реальность это врятли отразит.
>Ну а в чем проблема screen из дома расшарить?
непонятен смысл сего действа — кто, что и когда будет смотреть? Или я как-то неправильно понимаю смысл фразы «расшарить screen»?
>Сильная сторона чего? Если я влеплю memcached в приложение и на тестах оно надерет всем зад, это сильная сторона фреймворка?
если это можно сделать за 5 минут — да, это сильная сторона.
>Сравнение же голых приложений кажется мне надуманным сильно.
ну так мы ж писать будет не совсем голые приложения.
непонятен смысл сего действа — кто, что и когда будет смотреть? Или я как-то неправильно понимаю смысл фразы «расшарить screen»?
>Сильная сторона чего? Если я влеплю memcached в приложение и на тестах оно надерет всем зад, это сильная сторона фреймворка?
если это можно сделать за 5 минут — да, это сильная сторона.
>Сравнение же голых приложений кажется мне надуманным сильно.
ну так мы ж писать будет не совсем голые приложения.
Кто захочет тот и посмотрит, когда захочет и когда экран у тебя будет записываться :)
Я думаю что во всей троице это реально сделать, просто если думать об оптимизации можно много где схитрить, предлагаю вынести это в следующий этап, где уже демонстрировать как одно и тоже приложение написанное с использованием разных технологий можно оптимизировать
Голые в данном контексте — приложения не оптимизированные под продакшен.
Я думаю что во всей троице это реально сделать, просто если думать об оптимизации можно много где схитрить, предлагаю вынести это в следующий этап, где уже демонстрировать как одно и тоже приложение написанное с использованием разных технологий можно оптимизировать
Голые в данном контексте — приложения не оптимизированные под продакшен.
я как понимаю с asp.net не получится?
Возможно поучаствую на PHP, в зависимости от объёма проекта (я ограничен по времени).
Я бы не прочь поучавствовать (PHP + свой фреймворк). Или обязательно использовать известные фреймворки?
И что, например, если я буду использовать memcached?
И что, например, если я буду использовать memcached?
интересно было бы поучаствовать. любимый язык — perl :)
правда две существенные проблемы: 25-го меня не будет в питере (может я просто выложу результат — если он будет — куда; а если кому-нибудь будет интересно, то позже уже расскажу что там как); кроме этого не смогу пообещать пока не увижу задание, что будет время на разработку (ну потому что прямо сейчас есть дополнительная работа за которую платят, и просто жалко отдать сутки-двое пописать за интерес :), и зависит всё от того, есть ли уже что-то наработанное или нет по задаче.
а так — идея очень нравится.
правда две существенные проблемы: 25-го меня не будет в питере (может я просто выложу результат — если он будет — куда; а если кому-нибудь будет интересно, то позже уже расскажу что там как); кроме этого не смогу пообещать пока не увижу задание, что будет время на разработку (ну потому что прямо сейчас есть дополнительная работа за которую платят, и просто жалко отдать сутки-двое пописать за интерес :), и зависит всё от того, есть ли уже что-то наработанное или нет по задаче.
а так — идея очень нравится.
Думаю пора переходить уже к идее — что реализовывать. Возможно смогу подключиться на php+symfony.
С github пока не разбирался.
С github пока не разбирался.
>что реализовывать
а у вас есть предложения?
а у вас есть предложения?
у меня есть предложение %)
Мы вас слушаем :)
даже три банальных предложения:
а) чат; с регитрацией, ивсьотакое, с просмотром профилей, и личные сообщения
б) функицонал хабра: блоги личные и общественные, подсчёт кармы
в) реализовать функционал, необходимый для coffee-n-code, трансляции и общение
%)
а) чат; с регитрацией, ивсьотакое, с просмотром профилей, и личные сообщения
б) функицонал хабра: блоги личные и общественные, подсчёт кармы
в) реализовать функционал, необходимый для coffee-n-code, трансляции и общение
%)
первые 2 — это слишком банально, а вот (в) — интересный вариант… Напишете ТЗ подробнее?
первые два предлагается, именно, потому, что банально! %)
именно по банальным решениям имхо можно проверять разумность решения (=использование фреймворков)
если третье интерсно, попробую расписать подробней. но имхо там требуются неординарные технологические решения
именно по банальным решениям имхо можно проверять разумность решения (=использование фреймворков)
если третье интерсно, попробую расписать подробней. но имхо там требуются неординарные технологические решения
>именно по банальным решениям имхо можно проверять разумность решения (=использование фреймворков)
а если а и б решается установкой пяти плагинов и подгонкой дизайна — это допустимое использование фремворков? ;)
>если третье интерсно, попробую расписать подробней. но имхо там требуются неординарные технологические решения
пишите. попробуем оставить/адаптировать всё, что реализуемо.
а если а и б решается установкой пяти плагинов и подгонкой дизайна — это допустимое использование фремворков? ;)
>если третье интерсно, попробую расписать подробней. но имхо там требуются неординарные технологические решения
пишите. попробуем оставить/адаптировать всё, что реализуемо.
Дело в том, что для coffee'n'code я уже потихоньку делаю it-инфраструктуру, и пожалуй самым обидным будет если люди напишут что-то хорошее, а я не смогу имплементировать это в связи со своими какими-то причинами (например я не знаю groovy и не смогу дорабатывать/администрировать, а времени учить у меня нет), и чтобы никого не обижать я предлагаю отложить эту идею. Если кто-то реально хочет мне помочь с этой инфраструктурой, я готов обговорить лично.
>я не смогу имплементировать это в связи со своими какими-то причинами (например я не знаю groovy и не смогу дорабатывать/администрировать, а времени учить у меня нет)
с другой стороны ror/django/etc тоже не все знают и кто-то не сможет помочь в доработке ;)
а какие могут быть сложности с имплементацией вообще? сложные/обязательные моменты можно зафкисировать в ТЗ.
с другой стороны ror/django/etc тоже не все знают и кто-то не сможет помочь в доработке ;)
а какие могут быть сложности с имплементацией вообще? сложные/обязательные моменты можно зафкисировать в ТЗ.
Я выше уже высказал предложение — давайте сделаем опен-сурс проект помогающий проводить онлайн мероприятия. Без привязки к coffee'n'code, например я хочу сделать конференцию любителей жуков короедов с полноценным представлением онлайн, чтобы люди могли смотреть трансляцию, задавать вопросы и так далее, будто бы они находятся в аудитории, при этом естественно тяжелые вещи, такие как трансляция видео и пр. будут унесены на сторонние сервисы.
Третье — это интересно :)
Давайте напишем suite для онлайн мероприятий вообще вообще, без привязки к coffee'n'code. Выложим его в опенсурс и будет всем счастье.
ТЗ я напишу в течении двух дней, обещаю не показывать его, не обсуждать его ни с одним из участников самого мероприятия. :)
Функциональность на 12-16 часов разработки силами одного-двух человек.
ТЗ я напишу в течении двух дней, обещаю не показывать его, не обсуждать его ни с одним из участников самого мероприятия. :)
Функциональность на 12-16 часов разработки силами одного-двух человек.
Не успел до пятницы, но тем не менее вот оно: habrahabr.ru/blogs/Coffee_n_Code/57638/
если речь идёт о веб-тематике то можно открыть веб-лансер и на основе реальных предложений создать какую-нибудь искусственную задачу. только, на мой взгляд, нужно, чтобы этим занимались люди [но не один человек], не программирующие на чём-либо из вышеперечисенного [под веб, но знакомых с программированием]. так чтобы их выбор был основан больше на каких-то вещах не связанных с конкретными возможными языками или технологиями реализации, а, например, на практической ценности конечного решения, каких-то показателях эффективности инструмента.
лично я не готов дать какое-то предложение, потому как знаю, что часть задач, например парсинг, можно эффективно писать на перле, а часть — что-то типа «напишите хабр» — на перле писать скорее всего не стоит. ну и мне, как заинтересованному лицу, парсинг бы бы более интересен :)
лично я не готов дать какое-то предложение, потому как знаю, что часть задач, например парсинг, можно эффективно писать на перле, а часть — что-то типа «напишите хабр» — на перле писать скорее всего не стоит. ну и мне, как заинтересованному лицу, парсинг бы бы более интересен :)
Да, есть предложение!
Я в работе сталкиваюсь с CRUD-приложениями в которых должно быть разделение прав по ролям и данных между пользователями в рамках одной роли. Поэтому мне было бы интересно увидеть подобную реализацию на других платформах, сравнить подходы, обсудить плюсы/минусы.
Я в работе сталкиваюсь с CRUD-приложениями в которых должно быть разделение прав по ролям и данных между пользователями в рамках одной роли. Поэтому мне было бы интересно увидеть подобную реализацию на других платформах, сравнить подходы, обсудить плюсы/минусы.
>разделение данных между пользователями в рамках одной роли.
неосилил :(
в любом случае, это нифига не ТЗ для radrace.
неосилил :(
в любом случае, это нифига не ТЗ для radrace.
кстати, static.springframework.org/spring-security/site/reference/html/springsecurity.html наверняка умеет то, что вам нужно
что хотелось бы отметить: на этом заседании можно будет присутствовать виртуально, по крайней мере, авторам работ, если они иногородние с хорошим исходящим каналом.
во всяком случае, если у иногороднего возникнет такое бешеное желание рассказать и показать, то он мог бы попробовать
во всяком случае, если у иногороднего возникнет такое бешеное желание рассказать и показать, то он мог бы попробовать
thevery, мне кажется, что в ваш список 1-2-3-4-(5) в посте стоит ещё добавить пункт об экономической эффективности решения (чтобы авторы подготовились, а то прямо на месте на подобный вопрос может оказаться затруднительно дать какой-то содержательный ответ).
было бы интересно узнать про этот аспект для одной и той же задачи, решённой на разных языках.
было бы интересно узнать про этот аспект для одной и той же задачи, решённой на разных языках.
хм, а что вы подразумеваете под «экономической эффективностью»?
«за сколько можно данное решение продать»
необязательно указывать цифру или порядок, но поговорить про косвенные вещи какие-то: время на обучение языку/технологиям, стоимость используемого ПО, эффективность (или неэффективность) командной работы над этой конкретной задачей, много ли специалистов на рынке труда… ну не знаю. наверняка ещё что-то можно придумать.
необязательно указывать цифру или порядок, но поговорить про косвенные вещи какие-то: время на обучение языку/технологиям, стоимость используемого ПО, эффективность (или неэффективность) командной работы над этой конкретной задачей, много ли специалистов на рынке труда… ну не знаю. наверняка ещё что-то можно придумать.
ууу, это большая и обширная тема…
имхо сложно сравнивать даже php vs perl vs rails, не говоря уж о django и grails — специалистов по php на рынке выше крыши, а по grails — единицы, php-шных фреймфорков десятки, а grails один такой, выучить php java-программисту гораздо сложнее, чем grails, не говоря уж о том, что grails гораздо более эктерпрайзный итд… Итак, какое решение можно продать дороже?
имхо сложно сравнивать даже php vs perl vs rails, не говоря уж о django и grails — специалистов по php на рынке выше крыши, а по grails — единицы, php-шных фреймфорков десятки, а grails один такой, выучить php java-программисту гораздо сложнее, чем grails, не говоря уж о том, что grails гораздо более эктерпрайзный итд… Итак, какое решение можно продать дороже?
речь не о сравнении. речь про описание конкретной технологии, в которой специалист разбирается. в разрезе приближенном к деньгам.
а сравнивает и делает выводы после докладов уже каждый для себя сам на основе этих данных.
а сравнивает и делает выводы после докладов уже каждый для себя сам на основе этих данных.
а, вы имеете в виду примерно следующее:
«выучив технологию X за Y дней, вы сможете создавать сайты в N раз быстрее и M раз дороже»?
«выучив технологию X за Y дней, вы сможете создавать сайты в N раз быстрее и M раз дороже»?
«выучив технологию X за Y дней, вы сможете создавать сайты за в N дней и за бюджет M»
но мне бы было интереснее, чтобы конкретная трактовка всё же не навязывалась.
но мне бы было интереснее, чтобы конкретная трактовка всё же не навязывалась.
боюсь, что выбор фреймворка в случае не-php практически никогда не применим и ценность экономического обоснования стремится к нулю…
в больших проектах — с тем чем я сталкивался — не ограничиваются какой-то одной технологией/языком; как правило, составные части писаны на разных языках и это всех до некоторой степени устраивает.
так вот мне интересно, насколько эффективно, грубо говоря, вложение денег в реализацию какой-то части очередной системы на том или ином языке. для этого помимо технических вещей (что одно в таких-то случаях эффективнее другого по производительности, а в других — нет) нужно понимать ещё и финансовую и социальную сторону вопроса.
меня всё равно не будет на встрече, я уже написал выше. но смотреть выступления потом собираюсь. и подобные вопросы я задам докладчикам, если об этом не будет рассказано. просто эта информация может быть интересна не только мне.
как-то так.
так вот мне интересно, насколько эффективно, грубо говоря, вложение денег в реализацию какой-то части очередной системы на том или ином языке. для этого помимо технических вещей (что одно в таких-то случаях эффективнее другого по производительности, а в других — нет) нужно понимать ещё и финансовую и социальную сторону вопроса.
меня всё равно не будет на встрече, я уже написал выше. но смотреть выступления потом собираюсь. и подобные вопросы я задам докладчикам, если об этом не будет рассказано. просто эта информация может быть интересна не только мне.
как-то так.
а как на счет реализовать «web-конструктор компьютера». тут можно поплясать на над функциональностью со всех сторон. я не встречал в интернете такого рода сервиса. то бишь не с чего копировать — открытое поле для фантазии. да и проектик не большой.
«ээ… проц-винт-память-корпус?»
да, точнее проц-винт-память-монитро-видеокарта+система рейтинга(динамический показ очков с различных тестов).
«у разных компьютерных фирм уже есть подобное…»
как я понимаю имеется ввиду win-пиложение(они как обычно стандартные и приспособлены к сбору компонентов чисто для продажи ).
а в вебе встречали что-нидь подобное?
да, точнее проц-винт-память-монитро-видеокарта+система рейтинга(динамический показ очков с различных тестов).
«у разных компьютерных фирм уже есть подобное…»
как я понимаю имеется ввиду win-пиложение(они как обычно стандартные и приспособлены к сбору компонентов чисто для продажи ).
а в вебе встречали что-нидь подобное?
>да, точнее проц-винт-память-монитро-видеокарта+система рейтинга(динамический показ очков с различных тестов).
www.ixbt.com/video3/video-cpu-power-game-3dot5.shtml
>как я понимаю имеется ввиду win-пиложение(они как обычно стандартные и приспособлены к сбору компонентов чисто для продажи ).
да нет же, в вебе, вот например: ulmart.ru/configurator.php
www.ixbt.com/video3/video-cpu-power-game-3dot5.shtml
>как я понимаю имеется ввиду win-пиложение(они как обычно стандартные и приспособлены к сбору компонентов чисто для продажи ).
да нет же, в вебе, вот например: ulmart.ru/configurator.php
что-то вяло идеи предлагают. возьму на себя смелость предложить тему: on-line аукцион.
самый простой случай: участники — лоты — ставки
участник:
* выставляет лот на торги (сферический, в вакууме)
* делает ставки в пределах баланса на активные лоты
* не может делать ставку на свои лоты
лот:
* название (title)
* время окончания
* начальную стоимость
* минимальный шаг ставки
* опционально, выигрышная стоимость (по достижении которой лот выиигрывается автоматически)
* должна быть доступна история торгов по выбранному лоту (желательно, ajax- и/или comet-обновляемая)
ставка:
* размер ставки не должен превышать баланс owner'а
* пока ставка активна, средства в размере ставки на аккаунте лочатся
* если ставка выиграна, средства с аккаунта списываются
количество требований можно как уменьшить так и увеличить.
самый простой случай: участники — лоты — ставки
участник:
* выставляет лот на торги (сферический, в вакууме)
* делает ставки в пределах баланса на активные лоты
* не может делать ставку на свои лоты
лот:
* название (title)
* время окончания
* начальную стоимость
* минимальный шаг ставки
* опционально, выигрышная стоимость (по достижении которой лот выиигрывается автоматически)
* должна быть доступна история торгов по выбранному лоту (желательно, ajax- и/или comet-обновляемая)
ставка:
* размер ставки не должен превышать баланс owner'а
* пока ставка активна, средства в размере ставки на аккаунте лочатся
* если ставка выиграна, средства с аккаунта списываются
количество требований можно как уменьшить так и увеличить.
ps: такое чувство, что до 25го либо тему не определим, либо реализации никто не предложит :)
чем меньше времени на реализацию — тем интереснее
я не считаю scala хорошим вариантом для web front end'а. в своих проектах web gui я пишу на ror.
есть неплохой по задумке фреймворк lift. но там еще много доводить до ума нужно.
также на scala есть возможность использовать wicket. но wicket я не переношу :)
в принципе, фо фан, готов покодить на lift'е.
есть неплохой по задумке фреймворк lift. но там еще много доводить до ума нужно.
также на scala есть возможность использовать wicket. но wicket я не переношу :)
в принципе, фо фан, готов покодить на lift'е.
неплохой вариант.
а вы сами участвовать на scala'е будете?
а вы сами участвовать на scala'е будете?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Встреча 25 апреля. RAD race