andrei_golovin's Friends
[Most Recent Entries]
[Calendar View]
[Friends View]
Below are the most recent 25 friends' journal entries.
[ << Previous 25 ]
| Sunday, December 20th, 2009 |
ailev
|
12:16p |
Вышел стабильный Far 2.0 -- двухоконные менеджеры живут вечно
Вдруг кому нужно: официально вышел FAR 2.0 (стабильный билд 1263, 4 декабря 2009г., а первая версия появилась в 1996г.) -- http://www.farmanager.com/download.php?l=ruЯ, когда гляжу на эти двухоконные "файловые менеджеры", всегда вспоминаю неслучайность популярности этих файловых менеджеров и выигрышу их у всяких других интерфейсов. Правильный интерфейс в огромном количестве случаев заключается в двух окошках с сущностями, между которыми нужно указать отношение, построив тем самым факт (левая_сущность-отношение-правая_сущност ь), или выполнив действие: отношение это ведь всегда глагол! Впрочем, я это все писал уже ("Двухоконная лесопилка", июль 2007г. -- http://ailev.livejournal.com/498958.html, где я говорил про аутлайнер-коммандер): Дано: кучерявые (вплоть до ациклического графа) деревья (например, планы и связанные с ними расписания).
Требуется: их редактировать (создавать, удалять, копировать ветви и листья).
Решение: аутлайнер (ибо визуальное майндмэп-представление не столько для "нелинейной" работы, сколько для "последовательной/нарративной" презентации). И этот аутлайнер (в отличие от шикарного аутлайнера http://freemind.sourceforge.net/wiki/index.php/Main_Page) должен быть двухоконным (аутлайнер-коммандер): -- короткие узкие списки, которые можно "сканировать быстрочтением" (а картинки и "широкие тексты" -- нет). -- возможность задать команду (глагол действия) на клавиатуре. -- местоимение "там" (второе окно) вдобавок к "тут" (в отличие от просто командной строки и однооконного интерфейса). -- плотность представления информации много выше, чем в "графических представлениях" узлов и ребер. -- скролл только вертикальный (ибо еще и горизонтальный скролл в "красивой картинке дерева") путает жутко. Двухоконные редакторы онтологий тоже бывают: -- ОргМастер в одном из режимов редактирования ( http://bigc.ru/instruments/bigmasterpro/bm/om/). Это правильно (ибо два окна сущностей смотрят в одну их таксономию, а отношения показываются прямо между окнами). -- всякие мэпперы (например, плагин к NeOn -- http://neon-toolkit.org/wiki/Ontology_Mapping), но это паллиатив (окна в разные онтологии, а правильно -- чтобы можно было и в одну и ту же!). |
| Friday, December 18th, 2009 |
ailev
|
11:47p |
3D принтер для печати живых тканей из клеточных чернил -- уже есть.
Спасибо bablaw, указавшему на новость почти уже трехнедельной давности: 3D принтер для печатания живых тканей: http://www.invetech.com.au/download/dec%202009%20invetech%20delivers%20organovo%203d%20bioprinter.pdf, http://www.organovo.com/news.php?id=178 На снимке Scott Dorman (инженер в одной из двух фирм-создателей -- Organovo), печатает человеческие ткани из клеток пациента, для использования при создании новых кровяных сосудов. Микронная точность, лазерная калибровка, поэтому и возможна печать кровяных капилляров. Две печатающие головки -- одна для человеческих кленток, вторая для гидрогеля, поддерживающих веществ и прочих обеспечителей формы. Продажи с 2010, рынок ожидается только для исследователей. Но это пока. Это в продолжение к моим недавним постингам про новый 3D-принтер с прогнозом о скорой печати бифштексов ( http://ailev.livejournal.com/742703.html) плюс утверждению, что все самое главное в 3D принтерах уже произошло, и пора заняться разработкой дизайнерских программ для этой печати ( http://ailev.livejournal.com/749111.html). Про постинг о выращивании бифштекса я тоже помню ( http://ailev.livejournal.com/764050.html). Печатать и выращивать, печатать и выращивать... |
ailev
|
9:32p |
Реактор на бегущей волне TP-1
Побывал на семинаре с TerraPower ( http://www.intellectualventures.com/TerraPower.aspx), послушал доклад про их первый реактор на бегущей волне (TP-1), перекинулся парой слов с их сотрудниками на кофе-брейке. Чуда никакого нет: внутри он существенно похож на любой другой реактор. Бегущая волна делается механическими руками: горит центр цилинтра, а тепловыделяющие сборки по мере сгорания перемещаются специальным механизмом на периферию цилиндра, а свеженький обедненный уран в виде сборок же (очень похожих на используемые сегодня) перемещается в центр. И так 40 лет они перемешивают 8 тонн урана на 300МВт реакторе. В принципе, все то же самое, можно было бы делать на сегодняшних реакторах (если бы знать, как перемешивать, плюс из чего делать такие ТВС, плюс ответить еще на довольно многочисленные вопросы). Сгорать у них поначалу тоже будет 10% (что дает возможность использовать материалы с весьма консервативными 170с.н.а.), а все остальное -- это пока надежды на новые материалы (15% -- это 250с.н.а., передовой край сегодняшней материаловедческой науки. Но они мечтают о появлении материалов 500с.н.а., и тогда будет сгорать все 30%). Лицензию они получат на очень консервативную конструкцию "почти обычного реактора", а потом будут менять лицензию по мере понимания возможностей этого реактора (возможности же меняются в зависимости от того, как лихо они будут переставлять ТВС в корпусе). Строить будут не в США, ибо разницы между коммерческими и пробными реакторами в США нет -- поэтому отлицензироваться в США для строительства в 2020г. будет нереально. Тем не менее, 40 лет корпус первого же их реактора (дата введения в эксплуатацию 2020г.) теоретически остается запечатанный, а после этого все равно должна быть переработка топлива. Т.е. все проблемы с переработкой топлива и нераспространением не столько решаются, сколько отодвигаются на 40 лет. Основа всего их подхода -- моделирование. Основной моделирующий код был взят промышленный, и доработан. Доработку вел архитектор Windows NT -- сотрудник TerraPower рассказал, что он никогда не видел, чтобы так программировали: человек просто писал код (на фортране, ясное дело), как машинистка текст, сверху вниз с огромной скоростью, после чего этот код просто работал. Прикидки 3D сами они делают в AutoCAD, хотя их подрядчики работают со много более продвинутыми программами. Зато расчеты они делают на кластере в 1000 серверов. Да, все вопросы про горение с торием -- пока больше теория и реклама, сам торий не слишком горит, его нужно подмешивать к урану (и ехидный шепоток по-русски из угла: в ведь торий практически ни к чему подмешиваться не хочет, сплавить его не получается!). Работать поэтому поначалу будут только с ураном. Почему приехали в Россию? Исследования по облучению нейтронами материалов (а каждый процент выгорания -- это требования к материалам) можно делать только в России, Индии, Японии, и вот-вот можно будет делать в Китае. По этим точкам и организовали себе экскурсии. Вся кооперация в США уже налажена -- нет таких лабораторий (Аргоннская, Ливерморская, MIT и т.д.), где они бы не переманили людей в штат или не заключили контракт с самой лабораторией. Их 60 человек, штаб-квартара в Сиэттле (да, Редмонд по факту -- пригород Сиэттла, все не случайно). Живут все в разных местах (при тех лабораториях, откуда их переманили), раз в месяц слетаются в Сиэттл на очную встречу, раз в неделю обязательный "селектор" (по телефону), очень активно используются видеоконференции. Билл Гейтс и прочие бывшие майкрософтовцы активно участвуют в работе, а не просто дали деньги -- и это участие существенно помогает. Затею свою сами они считают очень рисковой (технологически нужно решить много-много проблем, плюс как-то купировать политические и экономические риски), но они надеются на выигрыш по-крупному. Я думаю, что будет как с той самой Windows NT: неважно, какие у этих реакторов в итоге будут технические характеристики и сколь чудесными будут принятые для них технологические решения, но эти характеристики и решения будут именно такими, благодаря которым эти реакторы будут в итоге стоять на каждом столе... пардон, в каждом дворе. Я напомню, что каждый раз, когда Биллу Гейтсу указывали на то, что его операционная система Windows плоха в первые годы ее распространения по миру, он смиренно отвечал: зато она самая дешевая. И впрямь, во много раз более крутой Unix в те поры продавался по три тысячи долларов штучка. С этими реакторами на бегущей волне будет ровно такая же история. Только урановый линукс представить себе пока нельзя... |
| Thursday, December 17th, 2009 |
ailev
|
10:16p |
Интеграция методов
Проблемы интеграции методов должны быть похожи на проблемы интеграции данных: те же различения мета-мета-модели, мета-модели, модели и экземпляров, те же проблемы разных уровней детальности описания, те же проблемы называния одинаковых объектов разными именами и разных объектов одинаковыми именами. Еще недавно репозиториев (библиотек типовых методов, reference method library) не было, а сегодня их полно -- строгие вокруг тех или иных метамоделей (библиотеки в формате SPEM, или OPFRO) -- нестрогие в форме PMBoK, BABoK и прочих ITIL. Интересности начинаются, когда нам требуется исполнение методов (enactment): интеграция должна быть не только на уровне описания библиотеки методов или собранного из библиотеки одного "типового", но и на уровне описания порожденного этим типовым методом процесса -- каковой процесс (workflow) должен будет исполняться машинами и людьми в расширенном предприятии (extended enterpise). И тут, я думаю, может помочь ISO 15926 с его подходом к интеграции данных, включая архитектуру RDL. Аналогии есть, и они более чем глубокие. Поэтому ISO 15926 может выступать как один из инструментов такой интеграции методов, равно как и образец архитектуры интеграции. Жизнь устроена так, что все новые и новые библиотеки типовых методов будут кодироваться во все более и более формальном виде, и нельзя ожидать, что где-то появится Главная Библиотека. Скорее, должна появиться какая-то онтология методов, которая позволит затем делать мэппинг к этой библиотеке для всех других методов. Поэтому у PraxOS может быть разные судьбы: -- репозиторий методов, такой же, как OPFRO, только русскоязычный и другой по составу (например, в нем будут методы Голдратта). Но лучше сразу вступить в OPEN Framework Repository Organisation, и просто добавлять методы туда. -- особое внимание к задаче интеграции методов и перехода к автоматизированному исполнению методов. Тогда PraxOS может выступать в качестве reference method library так же, как RDL в ISO 15926 (а в RDL ISO 15926 будет упихнут значительный кусок онтологии предметной области методологии). По-английски на эту тему я высказался тут: http://levenchuk.com/2009/12/17/situational-method-engineering-reference-method-library-as-a-way-to-methodworkflow-integration/ |
| Wednesday, December 16th, 2009 |
news
[ theljstaff ]
|
5:07p |
LiveJournal Major Notes: My Stats, My Guests, Holiday promotion, Yandex search, Whitelisting! 
Get to know My Guests. Want to know who's checking you out? You can now view the 100 most recent, logged-in users who visited your journal during the past 30-day period with My Guests. For those who prefer to fly under the radar, you can update your My Guests privacy setting here.
Introducing My Stats. If you have a Paid or Permanent account, you can now see detailed reports on how many people are visiting your journal, friends pages, and entries (wherever they're posted on LiveJournal). You can also view data on comments and RSS requests. My Stats is only available to Paid and Permanent account holders, but you can upgrade anytime. (FYI, an annual subscription costs less than a large pizza with everything on it, PLUS it's rumored to make you lose weight in your sleep!) For additional details on this feature, read this article in paidmembers.

Get ready to check your vital statistics!. To begin, mouse over Journal in the upper nav bar and select My Stats from the dropdown menu (Horizon) or select My Stats under Journal in the side bar (Vertigo). If you're using another design scheme, you can visit My Stats directly. You'll find My Guests on the My Stats tool bar.
Happy holiday promotion!We're delighted to tell you about our holiday coupons, which will help you share the love with your LiveJournal friends! If you have a Paid or Permanent account, you can send up to 10 LiveJournal Basic/Plus users a $10 coupon for an annual paid subscription now through January 15th, 2010. Recipients can upgrade for $9.95 (instead of $19.95) for one year by enrolling in our automatic payment plan or make a manual payment of $15 (instead of $25). Please note that these coupons are not transferable and cannot be used to renew existing paid accounts. If you're a Paid/Permanent user, you can send out your holiday coupons now!
Tweaks and Enhancements- The search is on: We've replaced our default search tool with one from Yandex, a leader in search engine technology. This means you'll get smarter, more granular results! To get started, enter your search terms and click the Go button to the left of the Find box on the upper right of the LiveJournal header. This will take you to the search landing page where you can further refine by Entries, Comments, People & communities, and FAQs. You can also access the search page directly.
- Whitelisting: We've released a new option to help you moderate your busy communities more efficiently. If an entry contains a link to a whitelisted (i.e., trusted) site, it will be posted automatically without need for moderator approval. If a post contains a link that is not on the whitelist, you'll be prompted to approve. To access this option, please visit settings for any community you maintain and select the third option in the Community Moderation box (located in the lower left-hand corner). Click the enable link to custom-edit your community's whitelist, which has been prepopulated with trusted domains. You can manually add or delete URLs in the text box. Please note: If you're the maintainer of an unmoderated community, you may see the radio button for this setting checked, even though it's not active. This is a known issue. Please select whichever option you prefer and click Save Changes at the bottom of the page. If you're happy with your current settings, then no need to do anything!
- TMI, dude: We've added some fun FREE sponsored vgifts! You can send up to 50 TMI vgifts to mutual friends (btw, you cannot send free vgifts to communities). If you're a Paid/Permanent user and you want to view sponsored gifts, click Show sponsored gifts on your homepage or visit the sponsored gift page. These vgifts will only be available through Wednesday, December 23rd.

You can view more awesome user content after the jump! ( Read more... )
Curtains
Thanks, again, for joining us. Until next time, stay snug! |
ailev
|
3:27p |
Ближайшие планы PraxOS
Первая из строящихся технологических пирамидок будет маленькой (и, надеюсь, поэтому быстровозводимой). Все названия условные, уровень исполнения -- "на коленке": 1. Все желающие поучаствовать ставят себе Protege, закачивают туда ISO 15926-2,4 и разбираются с ISO 15926-7,8. Это у нас будет развернута среда онтологического моделирования с накоплением знаний (Protege используется вместо привычного для всех UML или ER моделера). 2. Потом туда как-то добавляется метамодель ситуационной инженерии методов ISO 24744 -- чтобы подготовить возможность работать с репозиториями методов типа PraxOS, OPFRO и прочими Body of Knowledge ( foxtreme). 3. Для тестирования получившегося добавляется содержимое вебсайта www.opfro.org ( piter239) -- содержимое сайта парсируется, чтобы получились данные хоть в каком-то удобном для обработки формате, а не нынешние html-страницы -- содержимое сайта подводится под сделанную на шаге 2 метамодель (при этом, возможно, метамодель расширяется) в формате хранения данных этой -- содержимое сайта помещается в среду, позволяющую его удобно редактировать (скорее всего, Protege) и публиковать в виде вебсайта (скорее всего, публикационный плагин к Protege) 4. Русификация: -- метамодель методов (итог шага 2) расширяется, чтобы учесть возможность перевода на русский и другие языки. -- содержимое OPFRO начинает переводиться на русский 5. Делается метамодельный механизм (Reference Method Library, по архитектуре, максимально приближенной к ISO 15926 RDL), позволяющий различать оригинальное содержание OPFRO, содержание PraxOS и устраивать различные варианты гибридизации содержания (пополнение OPFRO из репозитория PraxOS и обратно). Это обеспечит международное партнерство методологов и инженеров методов. Больше RDL/RDM хороших и разных -- больше "песочниц" (sandbox из проекта IRING, чтобы онтологические эксперименты можно было вести, не мешая другим). 6. Заводится песочница RDL/RDM PraxOS и пополняется наработанным на настоящий момент содержанием методов (Голдратовщина и т.д.) -- кодирование методов ( vvagr). Ветвь: курс на автоматизированное исполнение предполагает следующие шаги, которые могут начинаться после шага 2 ( foxtreme): 3. Добавить в RDL PraxOS метамодель BPMN 2, чтобы иметь возможность детального моделирования процессов. 4. Добавить метамодель сервисов, чтобы было описание той инфраструктуры, которая обеспечивает выполнение всех конкретных (ситуационных) методов-процессов-проектов. Ветвь: курс на то, чтобы этим все могли пользоваться тоже может начинаться после шага 2: 3. Реализовать method composer на базе какой-то из language workbenches (Whole или ConceptBase). -- реализовать презентационные нотации (например, нотация ISO 24744) для методов. 4. Выполнить моделирование деятельности и инфраструктуры какого-то КонкОрг, чтобы подтвердить всю концепцию -- с использованием репозитория методов и метод композера (никакого автоматизированного выполнения, только картинки для обеспечения общего понимания и "справочный вебсайт"). Ссылки и объяснения использованных терминов не даю, все это уже обсуждалось у меня в блоге: кому интересно, тот все уже понял и заинтересовался. Русскоязычных материалов по этой проблематике пока нет. Кто еще хочет поучаствовать (бескорыстно), you are welcome (пришлите мне письмо, а я отвечу с приложением материалов, которых нет в открытом доступе). Эти ближайшие планы, конечно, не отменяют других дел и планов, а также подлежат ежемесячному, еженедельному, ежедневному и ежечасному пересмотру, но мультитаскинг (как минимум, свой) я все-таки буду стараться удавливать. |
ir_russia
[ theolga ]
|
2:48p |
|
ailev
|
2:22a |
Cherrypal Africa -- компьютер за $99
За $99 можно уже сегодня получить(в магазине http://www.cherrypal.com): The 7" Cherrypal was designed with developing countries in mind. The Africa is powered with an 400 MHz processor, 256 MB DDR / 2 GB NAND-flash and runs Linux (GMo) or Windows CE. Here are some more basics: Screen: 7 inch high-resolution TFT .(800 x 480 pixels) LAN:10/100M Ethernet Access WIFI: IEEE 802.11 b/g Ethernet RJ-45 Keyboard: QWERTY 86 keys Mouse&Touch pad:build-in touch panel, set two shortcut key,and support usb port mouse USB Port: USB 2.0 x 1 (aid external memory) USB 1.1 x 2 (aid keyboard & mouse only) External Memory : SD card , U-Disk , USB-HDD Card port: SD / MMC card slot (8GB) Battery: 7.4 V 1800Mha built in Lithium battery 1800MAH Last time:4 HRS Sound effect:build-in realtek sound effect chipset, Built in 2 x 0.5W Built in speaker 1 x microphone Weight:1.2kg Size: 213.5 x 141.8 x 30.8 mm |
ailev
|
1:30a |
|
ailev
|
1:15a |
BPMN 2.0 Beta 1
Вдруг кому нужно -- на http://www.bpmn.org/ выложен текст BPMN v2.0 Beta 1 (похоже, что это версия середины августа 2009, а выложена где-то 20 октября, судя по properties файла). BPMN (версии 1.0) по состоянию на 24 сентября 2009г. имела 61 реализацию и еще 4 запланированных. |
| Tuesday, December 15th, 2009 |
ailev
|
12:21p |
Десктоп суперкомпьютеры по500 евро за терафлопс: куда девать такую мощь
Оно, понятно, что это ненастоящий суперкомпьютер (из NVIDIA GTX295), но бельгийцы собрали настольный блок о 12 терафлопсах за 6000 евро, самый мощный десктоп в мире -- http://fastra2.ua.ac.be/ (там и видео есть). Куда девать такую мощь? Вычислять ненужное! Используется этот десктоп для 3D-томографии костей (повысили на тех же данных разрешение вдвое за счет того, что увеличили вычислительную мощность в восемь раз). Поглядел я на видео в примере, и понял: -- в основном там считаются данные, которые никогда и никому не понадобятся, их никто никогда увидеть не сможет, кроме крошечных кусочков. Я, конечно, все хорошо понимаю про голографию, томографию и прочие технологии, основанные на утверждении, что "все со всем связано, в каждой капле отражается весь мир". Ну да, сегодняшние алгоритмы таковы, каковы они есть. Нужно менять алгоритмику: требуется что-то придумывать с алгоритмами (или их использованием в вычислителе, что не сводится к замене алгоритма, а уже относится к инженерии), чтобы вычислять только то, на что сейчас смотрим -- и с тем разрешением, с каким сейчас смотрим. Если смотрим на кость, то вычислять с разрешением не бОльшим, чем пикселей на экране в этой кости. Ежели микроструктуру кости -- то вычислять не бОльший кусок микроструктуры, чем на том же экране помещается. Ежели мы это не смотрим, то и вычислять не нужно. А дальше, как с веб-картами: если двигать-зуммировать, то вычислять только то новое, что еще не вычисляли. Это будет быстро, "на лету". В САПР была та же самая задача: какая-нибудь подводная лодка с 4млн. деталями не хотела быстро крутиться на экране -- пока Dassault Systemes V6 не придумала вынимать из базы, рендерить (переводить данные в визуальную форму) и дальше уже крутить только то, что на этом экране помещается. Если вся лодка, то на экране крутится лодка -- винтики в ней не крутятся, их все равно не видно. Если вы сделали зум такой, что стали видны винтики, то тогда крутятся только винтики, а лодки уже не видно, и все лишнее из вычислений для отображения изымается. У веб-разработчиков такой прорыв был с AJAX -- как и в САПР, в революция произошла именно в тот момент, когда Google в своем почтовом интерфейсе стал обмениваться с сервером не целыми страницами, а только теми кусками, которые прямо сейчас нужны. Все необходимые решения в стандартах, серверах и браузерах к тому моменту уже давно (несколько лет как) присутствовали, но нужно было систематически провести эту идеологию в жизнь. И тут же скорости уже имеющихся каналов и производительности уже имеющихся компьютеров стало хватать для более-менее приличной работы, ранее доступной только в варианте толстых клиентов и локальной базы данных. Точно так и тут. Не нужны алгоритмы, которые восстанавливают всё. Нужны алгоритмы и способы их вызова, которые восстанавливают только то, что можно посмотреть "на лету" -- и с тем разрешением, которое можно разглядеть. Хотя запрограммировать такое будет явно дороже, чем купить 12терафлопс в настольном исполнении -- зато потом можно будет использовать массово, иметь сканеры чуть ли не в телефонах. |
ailev
|
10:45a |
Выполнение метода
Принятие к действию (enactment) метода в предприНятии (endeavour, проект/программа/организация) является существенным концептом современной ситуационной инженерии методов, в которой метод существует на трех уровнях абстракции: метамодель, методология (набор фрагментов и их связей) и конкретное предпринятие. Чем инструменты ситуационной инженерии методов лучше инструментов управления бизнес-процессами (workflow+business rules) или инструментов управления проектами? 1. Особое внимание уделяется накоплению знаний, в том числе и неформализуемых (guidance). Поэтому в поле внимания и поддержки попадает конструирование процессов/методов из шаблонов, а не "с нуля". Выделению повторноиспользуемых шаблонов уделяется значительное внимание -- в том числе и путем использования шаблонов высокого уровня абстракции (репозиториев методов). 2. Особое внимание используется обучению людей (хелпы, описания продуктов работы и т.д.), "встроенная документация по процессу/проекту". 3. Управление процессами и проектами обычно в разных инструментах, требует разных групп описаний (на PERT не видны продукты, в BPMN трудно со стадиями и контрольными точками -- хотя в свежей версии это может быть, уже и снято, нужно проверить). В любом случае, традиционные инструменты управления процессами/проектами несбалансированы для различных (инженерной, менеджерской, клиентской, организационной) групп описаний. 4. Существенный упор на группы описаний продуктов работы, команды людей и инструментов, а не только группу описаний процесса-проекта: подразумевается модель деятельности, а не только процесса/проекта. 5. Поддерживает постепенное создание метода (emergent process -- https://openair.rgu.ac.uk/bitstream/10059/220/1/Allison+and+Merali+ISTJ+paper+final.pdf). 7. Есть тенденция к объединению достоинств традиционного процессного подхода и ситуационной инженерии методов (например, SPEM+BPMN). 8. Тоже стандартизовано, но поскольку "процесс" рассматривается как шаблон, то выразимы более сложные случаи, нежели в традиционных проектах-процесссах (например, для ISO 24774 http://www.pa.icar.cnr.it/cossentino/AOSETF08/docs/UnisconKeynote.ppt): ( тут большая картинка примера нотации ISO 24744 для enactment )Примеры систем, которые как-то учитывают (или не учитывают) дальнейшее исполнение кастомизированного метода (инструмент+репозиторий): ( четыре системы ) |
| Monday, December 14th, 2009 |
ir_russia
[ theolga ]
|
1:48p |
Eversheds: Лондон может не удержать позицию второго по значимости финансового центра в мире
14.12.2009, Лондон 10:27:00 Лондон может не удержать позицию второго по значимости финансового центра в мире и в течение следующего десятилетия уступить ее Шанхаю. Об этом говорится в докладе международной юридической компании Eversheds, подготовленном на основе опроса 600 топ-менеджеров. Также, согласно исследованию, следует ожидать усиления роли индийской деловой столицы Мумбаи на глобальной финансовой сцене, передает Би-би-си. Источник: РБК |
ailev
|
1:10a |
Полуавтоматическое распознавание предметных областей
Много раз читал (и даже что-то писал) про ADOM (Application-based Domain Modeling, но только сейчас обратил внимание на самое интересное: они автоматизируют распознавание предметных областей: http://mis.hevra.haifa.ac.il/~iris/research/SDM/index.htmБерут модели нескольких приложений, и делают из них модель предметной области (метамодель) путем полуавтоматического обобщения (Semi-Atomated Domain Modeling Approach). Тренируются главным образом на проектном управлении и системах планирования производства -- http://mis.hevra.haifa.ac.il/~iris/research/SDM/SDMrepository.htmКак я понимаю, примерно так же действуют люди из тусовки ISO 15926: они делают конкретные мэппинги в конкретных приложениях, добавляя в RDL то, чего там для этого не хватает. В итоге предметные области будут иметь структуру, почерпнутую главным образом из приложений (а приложения имеют метамодели/онтологии, разработанные безо всякого domain-driven подхода. То есть никакие -- но в любом случае знание предметной области в них будет присутствовать, и его можно пытаться отловить). В любом случае, к ADOM нужно приглядеться внимательней. Это вся та же идея расположиться повыше в знаниевой трофической цепи, использовав чью-нибудь онтологическую работу как исходный материал. |
ailev
|
12:54a |
Pandora на 192Kbps
Не выдержал, и заплатил за Пандору ($36 в год, страшные деньги!). Их реклама и паузы совершенно не раздражали, но захотелось послушать музыку на 192Kbps. Послушал, и не пожалел. Оказывается, я вполне себе аудиофил. А поскольку у меня стоит профессиональная аппаратура, то на ней разница очень хорошо слышна (если кто хочет попробовать: слушайте звуки ударных инструментов. Если слышите реальные удары железок и деревяшек, то качество хорошее. А если эти железки и деревяшки бьют как бы через тряпочки разной толщины -- то эти тряпочки как раз у вас в звуковом тракте, у кого-то бьют через носовой платочек, а у кого-то и через толстое ватное одеяло). Напомню, я инструкцию по прослушиванию из России дал вот тут: http://ailev.livejournal.com/752249.htmlЭтот музыкальный сервис -- лучший. А вот риппер к ней (например, типа http://applian.com/replay-music/) покупать не хочу. Почему-то мне странна мысль записывать радио. Если уж что-то понравилось, то лучше сгулять в торрренты. |
ailev
|
12:29a |
|
ailev
|
12:27a |
Свежее интервью с Голдраттом
Вот новое (24 ноября 2009г.) интервью с Голдраттом по поводу его новой книжки "Разве это не ясно?! (Isn't It Obvious?) про розничную торговлю: http://www.scribd.com/doc/23593618/Clarke-Interviews-Eli-Goldratt (аудио -- http://media.libsyn.com/media/clarkeching/Clarke_Interviews_Eli_Goldratt_about_Isnt_It_Obvious.mp3). Он писал ее со сценаристами кино и ТВ -- ожидая, что они будут более склонны переделывать текст (ибо сценарии переделываются постоянно, вплоть до самой съемки). Так и случилось: книжка переписывалась неоднократно для точности, но из нее были убраны "размышления" -- она больше похожа на сценарий и поэтому читается легче, чем предыдущие книги. А сейчас он пишет книжку про изготовление под заказ (make to order), то есть переписывает "Ту самую Цель" -- хочет показать три больших скачка (одна из идей Голдратта заключается в том, чтобы не полировать очередное решение, а немедлено делать следующий Большой Скачок. В книжках он хочет показывать три таких скачка, чтобы был понятен также и паттерн непрерывного роста, а не только паттерн одного шага в этом росте). А наиболее важной из написанных книг Голдратт считает "The Choice". "Иголку в стоге сена" Голдратт писал, оказывается, чтобы показать как нужно делать искусственный интеллект (который как раз в годы написания этой книги загнулся на экспертных системах). Но на этот аспект книжки никто не обратил внимания -- а ведь Голдратт проблему планирования взял только как пример. Пример запомнили, а то, что он хотел этим примером показать, не заметили. TOC Голдратт считает больше похожей на физику, чем экономику -- настоящей наукой, и очень печется (как любой исследователь), чтобы старые результаты замещались новыми. А его ученики хотят, чтобы старые результаты новыми только надстраивались. UPDATE: вот еще комментарий по этому интервью -- о финансовом кризисе в восприятии Голдратта: http://vvagr.livejournal.com/1430101.html |
| Sunday, December 13th, 2009 |
ailev
|
11:08p |
Игры и упражнения в обучении
Упражнения на тренингах сейчас модно называть играми -- вот, например, сборник agile-ориентированных игр: http://blog.tastycupcakes.com/. От игры до театра один шаг -- и дальше на тренингах гибких людей появляются вообще уроки театральной импровизации ( http://www.infoq.com/news/2009/12/agile-teaching-games). По поводу этих игр обычно дискуссия: это трата времени или наоборот, единственный способ понять содержание?! Главное, что в этом деле даже эксперимента с воспроизводимыми результатами не поставишь, настолько все зависит от сочетания тех, кто пришел и того, кто пытается учить. Я обычно подобные упражнения даю не как "объясняющие" и "убеждающие в необходимости" использования каких-то практик (мой опыт показывает: объяснительная и убедительная сила этих упражнений весьма мала), а чтобы дать возможность поупражняться с новой онтологией, т.е. чтобы упражнение нельзя было бы выполнить, не воспользовавшись предложенными понятиями -- чтобы участникам приходилось проговаривать новые слова и строить осмысленные фразы с их использованием. Напомню, кстати, что изо всех традиционных метафор (обычно -- войны, или каких-нибудь боевых искусств) мне метафора игры сильно больше нравится. А для Agile метафора игры и вообще ключевая (напомню из http://ailev.livejournal.com/723608.html): вечная дискуссия про отличие agile-проектов от анархических, в которых работы не планируются никаким образом, и не используются никакие методы хранения. Интересно наблюдать, как сторонники дисциплины "водопадного" подхода не могут вообразить наличие любой другой дисциплины. С их точки зрения, если игра не идет по правилам шахмат, то игра обязательно идет без правил вообще -- и тогда она вообще не игра. Игры в футбол или в Го они не могут себе представить вообще. Объяснить, что у agile планирование и архитектурная работа подчиняются не менее жесткой дисциплине, чем при водопадном подходе, оказывается практически невозможным. Тем не менее, в жизни более чем регулярно встречаются ситуации, когда водопадный подход не применяется -- и эти ситуации почему-то автоматически приписываются к agile. Как будто, если я пишу не правой рукой, значит я автоматически пишу левой. Нет! Я ведь могу при этом писать ногой (с соответствующим ноге качеством письма), или даже вообще не писать. В ситуациях неприменения водопадного подхода agile чаще всего тоже не применяется, что бы об этом не говорили (например, если нет регулярных релизов, связанных с ними пересмотров выделения ресурсов, планирования итераций, то при чем тут agile?). Основные беды в проектном управлении не от водопада или agile-подхода, а от полного отсутствия метода. А для контраста приведу ровно обратный пример: отсутствие игры там, где ее все усматривают -- Second Life, в которой нет ни правил, ни цели, ни выигрыша... DISCLAIMER. Хейзингу я читал еще в нежном возрасте, и про play-game-perfomance СМД-методологов тоже знаю. |
ailev
|
9:22p |
Инженерия требований
Инженерия требований представляет собой одну из основных дисциплин системной инженерии, наряду с инженерией системной архитектуры, интеграцией и т.д. Ниже в духе требований ситуационной инженерии методов намечено содержание дисциплины инженерии требований. В каждой конкретной ситуации, характеризуемой природой создаваемой системы, используемыми инструментами и квалификацией людей, а также из наборов знаний других дисциплин в соответствии с выбранным методом управления жизненным циклом создаются конкретные описания жизненного цикла, которые затем используются в качестве учебных, справочных или нормативных для выполнения конкретного проекта. Для нижеприведенной структуры не предполагается какая-либо последовательность не только применения в проекте, но и изложения (например, в учебных курсах). Для развернутого представления подобного материала должен быть использован гипертекст. Так, в репозитории методов OPEN Process Framework ( http://www.opfro.org/index.html?Components/WorkUnits/Activities/RequirementsEngineering/RequirementsEngineering.html~Contents) можно найти в виде гипертекста обширный объем знаний, предусматриваемый предлагаемой нами структурой, хотя и не все знания. 1. Описание предметной области (онтологии) требований 1.1 Назначение требований 1.2. Требования как рабочие продукты (артефакт) 1.2.1. Отличия рабочих продуктов требований от архитектурных и проектных рабочих продуктов. Различение требований и ограничений. 1.2.2. Виды формулирования требований и требования к ним -- уровень неформальности: текст -- модели -- используемая парадигма (декларативные-процесссные) -- информационные модели (в том числе онтологии и метамодели для них -- как минимум, глоссарий). -- спецификации требований. Шаблоны информационных объектов. -- концепции 1.2.3 Виды использования -- автономные требования -- требования как задания на испытания и test-driven development -- требования как запросы на изменения и практики issue tracking 1.2.4 Виды по источникам -- требования и нужды заинтересованных сторон -- результат анализа требований 1.3. Классификация требований по их предмету 1.3.1. Контрактные, производные, эксплуатационные, к обслуживанию, обеспечению, обучению, прекращению использования, организационные, программные, аппаратные, оборудованию и т.д. -- разнообразие типов требований, каждый из которых требует своих рабочих продуктов, производящих и использующих их практик и квалификации инженеров требований 1.3.1. К методу разработки 1.3.2. К продукту 1.3.2.1. Функциональные 1.3.2.2. Нефункциональные -- качества (ценовая доступность, производительность, настраиваемость, надежность (защитимость (устойчивость, безопасность, защищенность, выживаемость), бездефектность (доступность, правильность, предсказуемость, надежность-стабильность)), экономичность, сопрягаемость, эксплуатационные характеристики, поддерживаемость, удобство в использовании -- к данным -- к интерфейсам -- ограничения (включают все виды требований) 2. Практики работы с требованиями 2.1. Место практик инженерии требований -- в жизненном цикле -- среди других инженерных дисциплин -- смежные практики: планировать усилия инженерии требований, готовить инфраструктуру управления требованиями и моделирования, управлять данными и конфигурацией требований, улучшать практики и т.д. 2.2 Стандартизация практик -- международные стандарты: ISO 15288 и ISO 12207, ISO 29148, IEEE 1233, для обоснования ISO 15026 -- частные стандарты: OPFRO, QUASAR 2.3. Разнообразие практик в части по природы системы ([программоемкая] система, модель бизнеса, предметная область, компонент, семейство продуктов, программное приложение, датацентр, завод и т.д.). Стандарты BABOK, ITIL. 2.4. Типовой набор практик 2.4.1. бизнес-анализ -- анализ клиента -- анализ конкурента -- анализ рынка -- анализ технологии -- анализ пользователя -- профилирование заинтересованных сторон -- выявление целей заинтересованных сторон -- разработка обоснования бизнес-модели 2.4.2. Предвосхищение (visioning) -- бизнеса, системы, приложения, компоненты 2.4.3. Разработка требований -- выявление требований -- переиспользование требований -- анализ (моделирование) требований -- прототипирование требований -- формулирование требований -- валидация требований 3. Обоснование выполнения требований (requirements case) 3.1. Рабочие продукты (декларации, аргументы, свидетельства) 3.2. Практики обоснования -- набор практик обоснования -- жизненный цикл обоснования 4. Команда, ее роли и требуемые квалификации -- источники требований -- разработка требований -- использование требований -- проверка требований -- управление требованиями 5. Инструменты инженерии требований -- автономные требования (типа IRqA etc.) -- требования-запросы (Dassault Systemes Requirements/Engineering Portal) -- модели требований (моделеры, в том числе интегрируемые в САПР) Замечания, предложения, вопросы? |
| Monday, December 7th, 2009 |
mindmaps
[ glamour_buddha ]
|
12:02a |
А есть в природе софт только для чтения майндмэпов?
Постоянно приходится работать с несколькими объемными картами, состоящими из большого количества картинок. Проблема в том, что МайндМенеджер при этом сильно тормозит. Поэтому встает вопрос наличия софта только для чтения ментальных карт. Если я не ошибаюсь, даже на заре своего появления такой софт был, и назывался именно MindJet, а MindManager - это была отдельная прога непосредственно для создания ментальных карт. Но сейчас ничего подобного пока не нашел. Либо может существует альтернативный МайндМенеджеру софт, удовлетворяющий следующим условиям: -наличие нотсов (заметок к каждой отдельной ветке), в которые можно вставить картинки. -если эти картинки в нотс можно вставить непосредственно из буфера обмена, а не из файла, - то вообще шикарно.) -Так как цель работы с картами - наискорейшее завоевание Галактики)), критична скорость работы, т.е. чтобы софт не загружал оперативную память компа. По сравнению с МайндМенеджером, естественно.) Спасибо за советы! |
| Saturday, December 12th, 2009 |
ailev
|
10:09p |
Политическое шаманство, австрийская школа, математические и прочие модели
Слушаю шаманское радио в Pandora (называется оно у меня shaman hey-heya), и время от времени музыкальный алгоритм подмешивает к шаманским бессмертным хитам типа animal sacrifice music творчество глубоко политизированной группы Quilapayun -- вот только что они спели шаманский хит "По долинам и по взгорьям" на испанском языке (ага, про волочаевские дни там хорошо слышится). Можно только пожалеть алгоритм классификации радио Пандоры, ведь в остальных случаях он вполне работает. Не стреляйте в компьютер, он классифицирует, как умеет. Если музыка шаманская, он ее так и отклассифицирует -- слов-то он не понимает... Как я понял, где-то в интернете открыли очередную ёмкость Пандоры, где моему системно-инженерному хей-хейя приписывают особую пропагандистскую силу в области австрийской экономики, и почему-то мою ученическую (потребительскую) позицию по отношению к австрийской школе именуют производительной (т.е. причисляют меня к числу австрийских экономистов, порождающих значимые в рамках этой школы результаты). Эй, я не ученый-австриец! у меня нет работ по австрийской экономике! Я не поднимаю планку австрийской школы, я просто пишу о ней в своем блоге! Я, конечно, высказываюсь по проблемам идиотизма нынешней власти (не только российской), но кто этого не делает? Не считать же эти высказывания научными статьями! Научные статьи должны определять понятия, вводить между ними связи, как-то формулировать гипотезы, соотносить эти гипотезы с реальностью хотя бы путем мысленного эксперимента. Ничего я этого не делаю. С другой стороны, я вполне мог бы это все делать -- и тогда я бы претендовал, что являюсь экономистом, даже если не вывел ни одной цифряной модельки. Я поражаюсь наивности наших мейнстримовских экономистов, которые пытаются рассуждать о разных моделях. Модели -- это мой хлеб, я занимаюсь профессионально моделированием много-много лет, еще со студенческой скамьи. Сейчас я занимаюсь моделеориентированной системной инженерией, поэтому не нужно считать, что в этом деле я не профессионал. Так вот, мейнстримовские экономисты ничего не понимают в моделях, заявляю ответственно -- они считают узкий класс численных моделек всем моделированием! Они считают, что в других моделях нет математики! Они смешат мои тапочки, они отстали на полвека. Современное моделирование тем и сильно, что от чисто численных моделей стремительно уходит в другие типы моделирования -- не менее строгие. Я даже не буду эту тему тут разворачивать, ибо надеюсь, что их в Гугле еще не забанили. Но если уж очень хочется, то могут начать, например, с моего еще летнего постинга http://ailev.livejournal.com/721298.html, где я как раз защищаю аналитическое моделирование от "критики справа". Или постинга http://ailev.livejournal.com/747288.html, где я приводил темы современных конференций по моделированию. Поэтому я бы нашим мейнстримовцам-экономистам вчинил бы встречный иск: не оболванивайте людей, не вешайте им шоры на глаза по поводу того, что является истинным моделированием и истинной экономикой. Австрийская школа двигается примерно так же, как современные исследователи: она порождает понятийные метамодели (а праксеология -- метаметамодели), при помощи которых можно выражать модели конкретной реальности. Абсолютно не понимаю, почему везде такое метамоделирование признается наукой (даже само слово метамодель встречается все больше в научных журналах сегодня, и довольно медленно идет в практику -- слишком свеженькая терминология), а вот в экономике метамоделирование наукой не признается. Я, замечу, именно поэтому и люблю австрийскую школу, что она серьезно относится к онтологическим и эпистемологическим вопросам, серьезно относится к своему методу. И не позволяет этот метод профанировать, сводя экономические понятийные модели только к аналитическим/математическим. Австрийская школа как раз и занимается Моделированием, а мейнстрим от нее в этом плане безнадежно отстал. Ничего, скоро экономмейстрим сообразит, что промахнул мимо поворота, и вместо нынешнего массового подсаживания на Modelica породит чудовищный UML 2 Profile для своих надобностей -- EconML -- и будет применять его так же неуклюже, как сейчас численные методы. А я буду лениво ругать этот EconML по той же линии, что сейчас ругаю самый модный язык мейнстрима системной инженерии -- SysML. И мейнстримные экономисты в очередной раз запишут меня во враги народа. Но это будет еще через десять лет, в мейнстриме обычно не торопятся. UPDATE: вот, кстати, еще пример пользователя экономавстризма -- http://screamager.deadjournal.com/445848.html (осторожно, там много абсолютно ненормативной лексики). Пора бы господам экономученым привыкнуть, что есть и просто пользователи их теорий -- и эти пользователи либо удовлетворены практическими результатами, либо нет. |
ailev
|
11:52a |
Тренды моделеориентированной системной инженерии
Любимый мой способ отследить современные тренды -- это поглядеть на темы последних конференций. Раз в пару лет проходит конференция по моделеориентированной системной инженерии. Вот темы MBSE'09 ( http://www1.technion.ac.il/_root/Announcements/info-links/MBSE_2009_Call_for_Papers_v12.pdf): -- языки и подходы концептуального (понятийного) моделирования -- онтологические основания для и требования из языка моделирования системной инженерии -- модели исследование операций и их отношение к системной инженерии -- стандарты для моделей системной инженерии -- освоение практик моделирования в организациях: подходы, достижения и полученные уроки -- UML и SysML: предмет, ожидания и наблюдения в отношении системной инженерии -- объектно-процессная методология для системного моделирования и поддержки жизненного цикла -- одна против множества групп описаний: согласование и интеграция моделей системы -- образование для целостного системного мышления и моделирования -- подходы к управлению сложностью в языках моделирования систем -- отношение между языками моделирования систем и методологией разработки систем -- методологии, процессы и языки моделирования: следствия и влияния -- информационная инженерия и инженерия программных систем: поддисциплина системной инженерии или отдельная область? -- инженерия человеческого познания (cognition) и человеческого фактора при проектировании систем -- промышленный опыт моделирования сложных систем: полученные уроки -- сравнительное изучение подходов и языков концептуального моделирования -- концептуальное моделирование для гибкой разработки систем -- автоматическое порождение артефактов (например, кода, документации) из моделей -- оценка и верификация моделей систем -- модели сервисной инженерии -- модели системной инженерии в промышленном контексте -- моделеориентированное управление проектом и управление жизненным циклом продукта -- моделеориентированное проектирование верификации и испытаний -- новые типы парадигм системной инженерии: биологическая, нано, и т.д. |
ailev
|
1:58a |
PraxOS и ISO 15926
Удивительно: именно я оказался человеком, который сообщил тусовке разработчиков ISO 15926 о стандарте SBVR. Теперь я им сообщил об OMG ODM ( http://levenchuk.com/2009/12/12/omg-ontology-representation-related-standards-odm-sbvr-and-iso-15926/). А всего-то я от них хочу, чтобы они определили стандарт, в котором готовить русскоязычную версию ISO 15926, но их интересует более широкий круг вопросов. Интересно, что наш план по разработке онтологии деятельности в принципе был одобрен -- и нам даже предложили по нему сделать рабочую группу PoscCAESAR (см. комменты к http://levenchuk.com/2009/12/10/activity-modeling-and-iso-15926/). Жаль только, что мы эту рабочую группу создать сами пока не в состоянии (мне кажется, что это все-таки не совсем по профилю деятельность для организационных консультантов -- быть лидерами методологического проекта). Но с удовольствием поучаствуем, буде она создастся -- как неосновной деятельностью заниматься методологией весьма полезно. После чего PraxOS будет иметь стандартизованную онтологию деятельности -- причем по-русски и по-ангельски, что приятно. И софт PraxOS сможет легко и свободно стыковаться с поддерживающими ISO 15926 САПРами -- если только не окажется, что рабочая группа, когда она соберется, сделает такую "консенсусную" онтологию деятельности, которая свяжет нас по рукам и ногам и поэтому будет нами же с негодованием отвергнута. Но попытка не пытка, быть стандартизированными на международном уровне -- это все-таки правильно. |
| Friday, December 11th, 2009 |
ailev
|
9:44p |
Введение в системную инженерию. Лекция вторая.
Первая моя лекция была пару недель назад (комментарий -- http://ailev.livejournal.com/757488.html, видео -- http://ailev.livejournal.com/757223.html). Сегодня мы с vvagr прочли вторую лекцию (хотя и не стали давать ее трансляцию в "прямом интернете", как в прошлый раз): Кто не хочет смотреть через плеер, вот одним файлом (268Мб): http://narod.ru/disk/15879642000/SE_intro2_11dec09.ASF.htmlПрочесть успели два небольших кусочка: -- описания и их множественность (читал я) -- жизненный цикл как совокупность инженерного, проектно-менеджерского и организационно-менеджерского описаний (читал vvagr) И совсем чуть-чуть затронули тему группировки практик (технические, проектные, орг.обеспечения проектов, соглашения) системной инженерии. На лекциях происходит все, как в жизни: каждый кусочек материала понятен, проблема только в том, как его применить по делу и в совокупности -- ибо понятность материала не гарантирует его применения. Я тут привел пример с игрой на саксофоне и на фортепиано. На саксофоне можно неделю учиться выдувать какой-то звук вместо шипения, а затем уже правильно нажимать на кнопочки в нужном порядке, чтобы получалась музыка. На рояле на кнопочки нажимать можно сходу -- учить этому специально не нужно. Но вот чтобы все эти кнопочки-клавиши в нужных сочетаниях вовремя нажимать -- обязательно нужна тренировка. Так и с системной инженерией. Каждое понятие ее понятно и прозрачно. Но чтобы оперировать всеми этими понятиями одновременно, требуется некоторая тренировка, "поворот мозгов" и "постановка мышления на рельсы". Пояснению чего на примерах и была посвящена часть лекции. Уже в кулуарах обсудили, что в ВУЗах всей этой "практической системной инженерии" не проходят примерно по той же причине, по какой предпочитают учить студентов истории философии, но не учить философствованию. |
| Thursday, December 10th, 2009 |
news
[ theljstaff ]
|
2:49p |
LiveJournal Major Notes: Notification fix, Snowflake cookie avalanche, LJLimerick, holiday vgifts! 
Tweaks and enhancements- As a number of you reported, a service interruption impaired sending and receiving notifications for a couple of days. This was due to an avalanche of snowflake cookies. We've removed the free snowflake cookie and unclogged the pipeline. Timely notifications should resume shortly. Please note that there's a backlog in our queues, so you'll be getting earlier notifications first. For more details, check out this post at
lj_maintenance. - In anticipation of the new year, we've embarked on a self-improvement kick to boost our backend (pun semi-intended). This will allow us to offer you a holiday promotion in the next few weeks (yes, we're listening and working very hard to make it happen). We sincerely appreciate your continued patience and support.
Holiday vgifts are here!

We've added some fantastic new vgifts to help you spread holiday cheer. We also hope you'll honor AIDS Awareness Month by purchasing virtual red ribbons. Priced at $2.99, we'll donate 100 percent of gross proceeds to IAVI.org (the International AIDS Vaccine Initiative) to support the development and global distribution of an affordable HIV vaccine.
Introducing: LJLimericksWe cordially here do invite you
To craft a fine limerick. Might you?
Each week, a new theme,
Then a poll, that's our dream
Winner posted on news to delight you!
In honor of all the brilliant writers on LiveJournal, we've created a brand new community: ljlimericks! Each week, we'll enter a handful of limericks into a poll (which we'll tuck snugly under an LJ-Cut). The winning poem will be published in the following newsletter. In addition, the author will receive a virtual blue ribbon! If you have the time, come drop us a rhyme. Please keep the "Nantucket" stuff on the downlow, since this is a youth-friendly community. Our first prompt is: Insomnia in winter.
Photos of the weekWe're back with more incredible images from our global photography community. Congratulations to sempre_marseeya, who has been awarded a virtual blue ribbon as the winner of our second lj_photophile poll.

We hate to squelch your creativity, but, as a courtesy to other users, please post only one photo at a time and keep the main photo no larger than 350x350 (so images display properly via mobile and on friends pages). You can link to a larger image and/or post photos under a cut. Just so you know, we select photos for the poll blindly, based on user comments and staff feedback. Please continue to vote, comment, and, of course, enjoy. You can check out the week in pictures and view more awesome user content after the jump! ( Read more... )
Curtains
Thanks, again, for joining us. Stay warm and safe out there! |
[ << Previous 25 ]
|