> «есть какая-то проблема»
Был такой 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]
Хотя, признаю, бывают (редкие) случаи когда БД испольуется как черный ящик «тупо для хранения» и к СУБД возлагается минимум специфических требований.
На текущем проекте пошли еще дальше и активно юзаем переменные окружения — по аналогии с приведенным выше, это как если бы все дефайны заполнялись из них. Это удобно, например для того, когда один application server фактически шарит между собой несколько окружений (dev, qa, uat) и нужно передавать приложениям разных окружений начальные коннективити данные (сервер, инстанс, схема) + если у вас фактически в одном инстансе крутится несколько разных окружений (dev, qa, uat). Переменные окружения в этом случае, добавляя гибкости, выполняют роль профиля, который легко подсосать и приложениям, и легко передать в деплоймент скрипт (через параметры) который развернет базу. Таких профилей создается по количеству энвайронментов, выбор происходит соурсингом соответствующего .sh файла (например удобно через менюшку в ~$APPLICATION_USER/.profile на этапе логина + shell альясы типа setdev2).
Из других deployment-related полезностей — «обкатка» в CI среде патч- и ролбек- скриптов (которыми во время релиза докатывается/откатывается prod база). Для этого настраивается отдельный энвайромент, на котором автоматом (по шедулеру, по коммиту) сначала разворачивается последний прод клон, потом применяется набор патчей для разрабатываемой новой версии, потом применяются ролбеки и снова патчи (back-and-forth, back-and-forth) — т.о. гарантируется некая повторяемость, консистентность и атомарность релиза в части изменения БД.
Предмет заметки, как мне кажется, выливается из того факта, что много людей занимающих позиции HR, к сожалению, таковыми не являются. Мне даже порой представляется, что большинство соискателей (в том числе и не самых интересных работодателю) давно об этом знают и умеют HR обходить так, чтобы к ним было меньше всего вопросов.
В этих условиях автор описал нормальный рабочий воркфлоу найма сотрудников, так оно и должно быть, так оно и бывает [иногда / в нормальных компаниях / в компаниях без HR / со слабым HR / etc ].
До школы было много общения с кружковыми БК0010-01, ДВК2М, ЕС, Спектрумами. Самый первый, по-настоящему мой — 91ый год, первый класс, родители собирают остатки обесценивающихся денег и на задышавшем капиталистическим дыханием ВДНХ покупают за безумные $1025 — 386 SX 25/33 с 4 Mb RAM, 60 MB HDD, FDD 3.5" + 5.25" и VGA монитором. Думаю в радиусе ближайших пары сотен км не было счастливее первоклашки — dos 5, qbasic, turbo pascal и куча игр, журналы «Монитор» с незабываемыми статьями. Улица и дворовые игры мне были не нужны и обошли стороной моё детство.
Где-то на медиане 90ых был первый апгрейд на P75, который гнался до 120 MHz + 8 Mb + CD 2x + SoundBlaster со встроенным нч-усилителем (тогда почти все такие были) и я вновь возглавил технологические топы домашних пк :)
Всю школьную молодость промышлял тем, что собирал пк своим друзьям, одноклассникам и даже учителям — помогая сильно сэкономить на покупке по-компонентно, тогда это было актуально. Был даже такой чит-код для получения доп. скидки у барыг митинского радиорынка — представится своим, сказав заветную фразу про профсоюз.
Когда я вижу, как результат кодогенератора допиливается руками (а иначе в 90% никак), мне всегда страшно становится от того, во что превратится код, если в модель надо будет внести изменения и перезапустить кодогенератор
Был такой 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]
Хотя, признаю, бывают (редкие) случаи когда БД испольуется как черный ящик «тупо для хранения» и к СУБД возлагается минимум специфических требований.
На текущем проекте пошли еще дальше и активно юзаем переменные окружения — по аналогии с приведенным выше, это как если бы все дефайны заполнялись из них. Это удобно, например для того, когда один application server фактически шарит между собой несколько окружений (dev, qa, uat) и нужно передавать приложениям разных окружений начальные коннективити данные (сервер, инстанс, схема) + если у вас фактически в одном инстансе крутится несколько разных окружений (dev, qa, uat). Переменные окружения в этом случае, добавляя гибкости, выполняют роль профиля, который легко подсосать и приложениям, и легко передать в деплоймент скрипт (через параметры) который развернет базу. Таких профилей создается по количеству энвайронментов, выбор происходит соурсингом соответствующего .sh файла (например удобно через менюшку в ~$APPLICATION_USER/.profile на этапе логина + shell альясы типа setdev2).
Из других deployment-related полезностей — «обкатка» в CI среде патч- и ролбек- скриптов (которыми во время релиза докатывается/откатывается prod база). Для этого настраивается отдельный энвайромент, на котором автоматом (по шедулеру, по коммиту) сначала разворачивается последний прод клон, потом применяется набор патчей для разрабатываемой новой версии, потом применяются ролбеки и снова патчи (back-and-forth, back-and-forth) — т.о. гарантируется некая повторяемость, консистентность и атомарность релиза в части изменения БД.
В этих условиях автор описал нормальный рабочий воркфлоу найма сотрудников, так оно и должно быть, так оно и бывает [иногда / в нормальных компаниях / в компаниях без HR / со слабым HR / etc ].
Где-то на медиане 90ых был первый апгрейд на P75, который гнался до 120 MHz + 8 Mb + CD 2x + SoundBlaster со встроенным нч-усилителем (тогда почти все такие были) и я вновь возглавил технологические топы домашних пк :)
Всю школьную молодость промышлял тем, что собирал пк своим друзьям, одноклассникам и даже учителям — помогая сильно сэкономить на покупке по-компонентно, тогда это было актуально. Был даже такой чит-код для получения доп. скидки у барыг митинского радиорынка — представится своим, сказав заветную фразу про профсоюз.