Я как раз об этом. Если предположить, ну просто помечтать, ну хоть на секундочку, что процентная разбивка голосов парламентариев должна хоть как-то отдаленно коррелировать с разделением мнений в обществе, то сие единогласие выглядит по меньшей мере странно. Может они просто что-то знают, чего не знаем мы, эдакий sacred knowledge? :)
за проголосовали 441 депутат из 450 возможных (http://ru.wikipedia.org/wiki/%D0%93%D0%BE%D1%81%D1%83%D0%B4%D0%B0%D1%80%D1%81%D1%82%D0%B2%D0%B5%D0%BD%D0%BD%D0%B0%D1%8F_%D0%B4%D1%83%D0%BC%D0%B0)
однако
кто-нибудь еще может припомнить столь единогласное голосование по какому-либо вопросу?
кто-то еще верит в существовании парламентской оппозиции? :)
«либо не оставляли его вообще» — вы агитируете за одобряюще-сопливое улюлюканье в отсутствии конструктивного скепсиса? Бросьте, откройте глаза и смело оглянитесь по сторонам, а не трепещите над своей кармой. Мне плевать на 99% юнцов-хабродрочеров.
Не впечатлило. Или может идеи не понял? Я думал прототипирование подразумевает не только разработку взаиморасположения элементов интерфейса, но и элементарное программирование их реакции / поведения. А тут получилось что-то вроде MS Visio с урезанным набором элементов. Даже в HTML не экспортнуть результат. Буэээ
> «есть какая-то проблема»
Был такой issue в предыдущем проекте — база изначально жила в Power Designer, из которой генерился DDL. Надо было добавить deferred constraints, которых не было по умолчанию предусмотрено в IDE. В итоге пришлось копаться в шаблонах, из которых PD генерил код или искать еще какой-то workaround. Чуть позже, когда количество костелей к IDE подобралось к критической отметке, PD был заброшен. Так что проблема существует, факт.
> «Это ведь не код сгенерировать, который реализуют какую-то логику, а описание структуры»
На самом деле, у всех IDE что мне встречались, которые позволяют моделировать структуру и писать код — есть куда большая беда, они в отсутствии живой базы не способны этот код отвалидировать. Так что существование dev-инстанса (или несколько шире — нескольких окружений разработки) как места разработки «на живую», с последующим внесением кода в репозитарий, мне представляется несколько более удобным вариантом.
А подход, когда структуры генерятся из IDE, а обвязка цепляется из отдельных текстовых файлов выглядит еще более разбродной. Хотя тут конечно же вопрос силы воли сопровождающего.
Ладно, копья в сторону.
Искренне интересно ваше мнение по одному вопросу архитектурному. Есть типичная задачка — организация расширенного CRUD интерфейса к неким данным (файлы, фотографии, письма, дела, тикеты и т.п.). Под расширенным я скорее всего держу в голове функциональность гмейла, где есть поиск по различным атрибутам, множественное выделение, тэггирование, правила и пр. Насколько я понимаю, задача эта в ваших продуктах неоднократно решена.
Не встречалось ли вам среди опенсорса готовых решений достаточной абстракции для решения конкретно этой задачи? Я смотрел в сторону автогеренации кода во фреймворках Symphony, выглядит неплохо, но может есть что-то еще, более, так сказать, sophisticated? Как вы лично решали эту задачу в ваших продуктах?
Не-не-не, идея не в том чтобы уповать что сделает кто-то за нас. Мой тенс в том, что перед тем чтобы что-то начинать [в опенсорсе] надо изучать предметную область, и по возможности вливаться в существующий проект, а не велосипедить свой.
Не смотря на то, что у вас велосипед вышел вполне симпатичный, вам сил, энергии и интереса хватить не дать ему умереть?
Для этого всегда достаточно уточнить — какой срок на обдумывание они хотят взять + честно и открыто сказать, что ты тоже не собираешься сидеть у окошка в платочке, отменив все запланированные на этот период собеседования с другими конторами.
У меня на практике было пару таких мест, крупные IT контоы от 1000+ сотрудников, в которые процесс трудоустройства занимал по несколько недель. В первое я тогда не пошел, не дождался, завтраками кормили каждый день, хотя спустя месяц офер мне все-таки сделали.
Потом уже, поработав в таких конторах, я понял, что основной фактор подобных тормозов (исхожу из посылки что ты интересен работодателю) — это бюрократия (каждый кандидат утверждается/собеседуется у кучи людей) на которую накладывается нестабильность людей (один сегодня не может, другой заболел, третий в отпуске и т п).
Большие конторы куда более инертны при поиске кандидатов, надо это понимать и не принимать близко к сердцу, когда тебе следующее собеседование назначают через пару недель от текущего.
Не поймите меня не правильно, просто вот это примерно как если бы мне нужно было убрать комнату я бы начал со сборки пылесоса. Есть действительно 2 проблемы — хранение фотоархива (место, бекапы, доступность) и управление им (тэги, лица, структура и пр.). А есть программные решения которые позволяют все или часть этих проблем решить. Составьте сравнительную табличку с характеристиками, почему ваш продукт лучше/хуже того же Фликра например или Яндекс.Фото.
На самом деле мне другое интересно, Ostora.Photo это ведь сингл юзер веб-приложение, я ж его с друзями шарить не смогу (комменты под фото, пользователи/права, аутентификация из разных сервисов)?
За любое опенсорс активити — плюс.
А вот юзкейсы очень спорны, потому как подобное решение еще надо мейнтейнить, хостинг не бесплатен опять таки + надо озаботится резервированием. У макоюзеров есть iPhoto + Time Machine, у виндовс юзеров есть тоже что-то подобное, про линух юзеров молчу — у них вообще есть все. Кроме того есть куча веб-сервисов (Google Picassa, Flikr, Photo.(Yandex/Mail).ru, iCloud/Mobile.Me и т. п.) которые решают озвученные проблемы за раз.
Ох, едрить, три года теме :) Вопрос автору, что-нибудь с тех пор на рынке вспомогателей для деплоймента новое / интересное появилось? Может быть автор уже на что-то другое перешёл, и если так, то по каким причинам?
Ну и подозреваю, что можно воткнуть в него допсценарии в разные точки, например перед пересозданием симлинки заглушить вебсерер, а после поднять обратно или зарелоадить?
Он «из коробки» поддерживает разные логические энвайроменты (когда на одной машине крутятся несколько разных версий dev / qa) или это уже забота деплой инженеров по разнесению?
Вообще интересная штука, спасибо.
Окружений никогда не хватает, факт, и бюрократия доставляет, согласен. Поэтому я и упомянул идею когда один физический oracle инстанс шарится между разными окружениям. Например CI может быть на том же инстансе где у вас уже есть DEV, для разделения схем можно использовать суффиксы / префиксы — например HR_DEV1, HR_DEV2, HR_CI — три схемы в одном инстансе которые относятся к разным энвайроментам. ДБАшники могут и не заметить чита, их лишь надо попросить аккаунтов создать, а тейблспейсы для простоты поддержки можно заюзать существующие. Придется мириться правда (возможно) с некоторым даунгрейдом перформанса, но зато «в теле такая приятная гибкость образовалась» (с) :-)
По поводу выгрузки прода, совсем не обязательно каждый раз обновлять CI из свежеиспеченного физического дампа прода. Если предположить что структура прода между релизами не меняется (исключение — если quick fix выкатываете) то дамп можно сделать сразу после релиза, и потом его использовать вплоть до следующего релиза. Здесь исхожу из предположения, что данные, их свежесть, для обкатки не так важны.
А если подумать в сторону логического дампа, который требует только SCHEMA OWNER чтобы подропать все что было и пересоздать заново, то ДБАшники точно ничего не узнают :-)
Буду с интересом следить за следующими вашими статьями, пишите!
No offence, я лишь вторю Кайту, в той части, где он говорит про должное понимание особенностей (и разницы этих особенностей) субд: это не только синтаксис, это куда более важная разница в реализации MVCC которая [потенциально] ведет к необходимости по-разному реализовывать логику самого приложения.
Видимо вы пошли по второму пути, где учитываете эти особенности, оборотной стороной этой медали миритесь с возросшей сложностью.
Что за продукт, если не секрет, к которому такие требования?
> Зачем нужна беседа в HR после собеседования с руководителем я тоже не понимаю.
В зависимости от обсуждаемых с HR вопросов. Если денежных, то это своего рода способ изоляции твоего будущего руководителя от твоей будущей зарплаты.
Извините, не удержался.
[режим простых истин on] Делая приложение независимым от СУБД вы либо теряете бенефиты, которые предлагает та или иная СУБД (перфоманс как следствие) либо, погружаетесь в условную компиляцию или уровень абстракций от СУБД, пишите много кода, чтобы ваше приложение одинаково хорошо работало с _нексколькими_ выбранными СУБД. [режим простых истин off]
Хотя, признаю, бывают (редкие) случаи когда БД испольуется как черный ящик «тупо для хранения» и к СУБД возлагается минимум специфических требований.
однако
кто-нибудь еще может припомнить столь единогласное голосование по какому-либо вопросу?
кто-то еще верит в существовании парламентской оппозиции? :)
Простите меня, но это аргументация ребенка. Сударь, вы меня утомили.
Был такой issue в предыдущем проекте — база изначально жила в Power Designer, из которой генерился DDL. Надо было добавить deferred constraints, которых не было по умолчанию предусмотрено в IDE. В итоге пришлось копаться в шаблонах, из которых PD генерил код или искать еще какой-то workaround. Чуть позже, когда количество костелей к IDE подобралось к критической отметке, PD был заброшен. Так что проблема существует, факт.
> «Это ведь не код сгенерировать, который реализуют какую-то логику, а описание структуры»
На самом деле, у всех IDE что мне встречались, которые позволяют моделировать структуру и писать код — есть куда большая беда, они в отсутствии живой базы не способны этот код отвалидировать. Так что существование dev-инстанса (или несколько шире — нескольких окружений разработки) как места разработки «на живую», с последующим внесением кода в репозитарий, мне представляется несколько более удобным вариантом.
А подход, когда структуры генерятся из IDE, а обвязка цепляется из отдельных текстовых файлов выглядит еще более разбродной. Хотя тут конечно же вопрос силы воли сопровождающего.
Искренне интересно ваше мнение по одному вопросу архитектурному. Есть типичная задачка — организация расширенного CRUD интерфейса к неким данным (файлы, фотографии, письма, дела, тикеты и т.п.). Под расширенным я скорее всего держу в голове функциональность гмейла, где есть поиск по различным атрибутам, множественное выделение, тэггирование, правила и пр. Насколько я понимаю, задача эта в ваших продуктах неоднократно решена.
Не встречалось ли вам среди опенсорса готовых решений достаточной абстракции для решения конкретно этой задачи? Я смотрел в сторону автогеренации кода во фреймворках Symphony, выглядит неплохо, но может есть что-то еще, более, так сказать, sophisticated? Как вы лично решали эту задачу в ваших продуктах?
Не смотря на то, что у вас велосипед вышел вполне симпатичный, вам сил, энергии и интереса хватить не дать ему умереть?
codex.gallery2.org/Gallery2:About
опенфото из ссылок выше умеет (или говорит что умеет)
en.wikipedia.org/wiki/Coppermine_Photo_Gallery
И вот это может оказаться полезным:
en.wikipedia.org/wiki/Photo_gallery_comparison
Ну да чего я буду вас гуглом учить пользоваться, затыкаюсь на сим
У меня на практике было пару таких мест, крупные IT контоы от 1000+ сотрудников, в которые процесс трудоустройства занимал по несколько недель. В первое я тогда не пошел, не дождался, завтраками кормили каждый день, хотя спустя месяц офер мне все-таки сделали.
Потом уже, поработав в таких конторах, я понял, что основной фактор подобных тормозов (исхожу из посылки что ты интересен работодателю) — это бюрократия (каждый кандидат утверждается/собеседуется у кучи людей) на которую накладывается нестабильность людей (один сегодня не может, другой заболел, третий в отпуске и т п).
Большие конторы куда более инертны при поиске кандидатов, надо это понимать и не принимать близко к сердцу, когда тебе следующее собеседование назначают через пару недель от текущего.
gallery.menalto.com/
www.zenphoto.org/
piwigo.org/
www.tinywebgallery.com/en/main.php
www.plogger.org/
phpalbum.net/
coppermine-gallery.net/
www.thephig.com/
studio.quintalinda.com/help/tools/openfoto-open-source-photo-gallery-script/
+ и еще с сотню думаю наберется
www.google.ru/search?aq=1&oq=open+source+photo+&sugexp=chrome,mod=10&sourceid=chrome&ie=UTF-8&q=open+source+photo+gallery
На самом деле мне другое интересно, Ostora.Photo это ведь сингл юзер веб-приложение, я ж его с друзями шарить не смогу (комменты под фото, пользователи/права, аутентификация из разных сервисов)?
А вот юзкейсы очень спорны, потому как подобное решение еще надо мейнтейнить, хостинг не бесплатен опять таки + надо озаботится резервированием. У макоюзеров есть iPhoto + Time Machine, у виндовс юзеров есть тоже что-то подобное, про линух юзеров молчу — у них вообще есть все. Кроме того есть куча веб-сервисов (Google Picassa, Flikr, Photo.(Yandex/Mail).ru, iCloud/Mobile.Me и т. п.) которые решают озвученные проблемы за раз.
Он «из коробки» поддерживает разные логические энвайроменты (когда на одной машине крутятся несколько разных версий dev / qa) или это уже забота деплой инженеров по разнесению?
Вообще интересная штука, спасибо.
По поводу выгрузки прода, совсем не обязательно каждый раз обновлять CI из свежеиспеченного физического дампа прода. Если предположить что структура прода между релизами не меняется (исключение — если quick fix выкатываете) то дамп можно сделать сразу после релиза, и потом его использовать вплоть до следующего релиза. Здесь исхожу из предположения, что данные, их свежесть, для обкатки не так важны.
А если подумать в сторону логического дампа, который требует только SCHEMA OWNER чтобы подропать все что было и пересоздать заново, то ДБАшники точно ничего не узнают :-)
Буду с интересом следить за следующими вашими статьями, пишите!
Видимо вы пошли по второму пути, где учитываете эти особенности, оборотной стороной этой медали миритесь с возросшей сложностью.
Что за продукт, если не секрет, к которому такие требования?
В зависимости от обсуждаемых с HR вопросов. Если денежных, то это своего рода способ изоляции твоего будущего руководителя от твоей будущей зарплаты.
[режим простых истин on] Делая приложение независимым от СУБД вы либо теряете бенефиты, которые предлагает та или иная СУБД (перфоманс как следствие) либо, погружаетесь в условную компиляцию или уровень абстракций от СУБД, пишите много кода, чтобы ваше приложение одинаково хорошо работало с _нексколькими_ выбранными СУБД. [режим простых истин off]
Хотя, признаю, бывают (редкие) случаи когда БД испольуется как черный ящик «тупо для хранения» и к СУБД возлагается минимум специфических требований.