Спустя 4 года и 5 месяцев решил поднять из бэкапа свой блог. Что с ним делать дальше ещё не решил. Пока обновил WordPress и переехал на новый хостинг — VPS-ка от reg.ru. Пока всё устраивает. До этого, когда-то давным давно, пользовался услугами brim.ru, потом кажется DigitalOcean, потом очень долгое время блог жил на виртуалке, которую друзья дали. Это был очень крутой подарок.
Мне первые несколько лет было интересно писать заметки и статьи в блоге. Потом надоело, наверное перегорел. Когда поднял бэкап, обнаружил в черновиках пару недописанных статей — одна про JMX, другая «поток мыслей» про будущее ИТ. Буду думать, что с ними делать. Наверное просто удалю. Смысла нет, поскольку многое поменялось за это время. Персональные блоги почти все переехали на medium, а сайты сейчас делают на тильде (а может уже и нет). Да и в целом мир изменился, я изменился. Java изменилась. WordPress изменился. Его новый интерфейс непривычен, но обещает новые возможности.
На этом всё. Пусть это будет первая пробная статья после длительного перерыва.
Во-первых (и это мое личное мнение), использовать такую нотацию в исходниках на Java действительно нелепо.
Во-вторых, когда-то давно я grep-ом проходил исходники андроида (кажется 16-ый API Level) и там нотация не соблюдалась. Более того она была некорректной (статические поля с m-префиксом).
Коворкинг интересен тем, что в нем можно встретить интересных людей.
Следующая история произошла после краткой беседы с Димой Гарником, арт-директором небольшой дизайн-студии.
У Димы была идея создать простой сайт для автовизиток. Идея несложная, но интересная. Вы заходите на сайт, указываете номер телефона и сообщение (например: «Мешает машина? Звони!«). Затем вы получаете развертку, из которой можно собрать симпатичную машинку. Развертка — это PDF-файл, который можно распечатать на листе бумаги формата А4 и собрать. Самое главное: сборка идет как «оригами», т.е. без ножниц и клея, нужны только «прямые» руки и время.
В итоге получается такая штука:
Собственно, нужно было как-то реализовать генерацию этих разверток.
Так совпало, что Дима подошел и рассказал про свою идею именно в тот момент, когда мы с соседом пили кофе и вели досужие разговоры на тему: «что бы такого сделать интересного и не сложного». Димина идея показалась интересной и не очень трудоемкой.
Генерацией PDF-файлов мне уже приходилось заниматься в прошлом (хотя это и была, в основном, генерация документов и отчетов с использованием различных выборок из БД — принципиальной разницы я не видел).
В общем, я сделал эту штуку.
Про FOP, SVG, PDF
Приблизительный план, что и как нужно делать, в целом, был понятен сразу:
1. Берем рисунок в векторе.
2. Сохраняем его в SVG-формате.
3. Поскольку SVG — это обычный XML, то менять в нем содержимое (номер, сообщение, цвет и т.д.) несложно.
4. Прикручиваем преобразователь SVG → PDF.
5. Проверяем, что все это работает, и делаем к этому «обвес», который обрабатывает HTTP запросы и отдает пользователю PDF-файл.
6. Прикручиваем дизайн или интегрируем с текущим сайтом.
В целом, все прошло согласно плану. За исключением следующих моментов:
1. Проблемы со шрифтами.
Конечно, все зависит от SVG-файла, но, возможно, возникнут сложности с кириллическими шрифтами после развертывания на сервере (т.е. на Linux-е).
Решение: поставить недостающие (зависит от того, какие нужны) шрифты.
Например, как-то так:
apt-get install ttf-mscorefonts-installer
2. Еще раз проблемы со шрифтами.
У того, кто раньше работал с Apache FOP, могут возникнуть сложности в более тонкой настройке конфигурации.
Дело в том, что формат файла для настройки PDFTranscoder-а отличается от привычного fop.xconf!
Если кратко:
//Создает перекодировщик. Кроме PDF, если верить документации есть перевод в PostScript, EPS.
Transcoder transcoder =new PDFTranscoder();// Если нужно "вшивать" свои шрифты, требуется дополнительная настройкаtry{
DefaultConfigurationBuilder cfgBuilder =new DefaultConfigurationBuilder();
Configuration cfg = cfgBuilder.buildFromFile(newFile("pdf-renderer-cfg.xml"));
ContainerUtil.configure(transcoder, cfg);}catch(Exception e){thrownew TranscoderException(e);}
//Создает перекодировщик. Кроме PDF, если верить документации есть перевод в PostScript, EPS.
Transcoder transcoder = new PDFTranscoder();
// Если нужно "вшивать" свои шрифты, требуется дополнительная настройка
try {
DefaultConfigurationBuilder cfgBuilder = new DefaultConfigurationBuilder();
Configuration cfg = cfgBuilder.buildFromFile(new File("pdf-renderer-cfg.xml"));
ContainerUtil.configure(transcoder, cfg);
} catch (Exception e) {
throw new TranscoderException(e);
}
Сейчас это кажется очевидным. Но тогда, чтобы понять, как избавиться от крякозябр в картинках, пришлось потратить почти столько же времени, сколько на всю оставшуюся разработку.
На этом технические детали хотелось бы оставить в стороне и написать пару слов про дизайн и его значение.
Как правило, чем более «программистская» контора, тем сильнее доминирует принцип — делаем «not pretty but functional«, а затем дизайн (если остались деньги).
Все бы хорошо, но бывают заказчики, которым потом жалко тратить деньги на нормальный дизайн: им главное, чтобы работало. Как правило, это касается разработки внутренних систем. В целом, это нормальная бизнес-ситуация: лишних денег на «красивости» часто нет. Правда в том, что в итоге сотрудникам некоторых компаний приходится годами пользоваться унылым корпоративным ПО.
Если приводить аналогию, то в таком случае, сайт для создания автовизитки без дизайна выглядел бы примерно так: Без дизайна
Для сравнения, вот так он выглядит сейчас: С дизайном
С другой стороны, если поставить дизайн во главу угла, может получиться ситуация, когда дизайн есть, а функциональности нет.
Красиво выглядит? Да, бесспорно! Работает? К сожалению, нет. При этом могут пройти месяцы, пока из красивого получится работающее. Ситуация может усугубиться, если дизайнер «понапридумывает» разного, а это потом не будет работать или окажется невозможным реализовать.
Многие скажут: «К чему эти банальности? Это и так понятно!». Понятно, но хотел бы повторить: нормальный дизайн — это не опция, это неотъемлемая часть хорошего программного продукта. Такая же составляющая, как и его функциональность.
PS: Может кто-то знает нормальные курсы дизайна по UI/UX? Не про «сферического коня в вакууме», а про конкретные практики — как пользоваться инструментами. И не про общие принципы: что нужно выравнивать, что какие-то цвета плохо сочетаются и т.д., — про это многое уже известно.
Проблема в том, что иногда по мелочи нужно что-то сделать (например, у меня бывают вопросы, как в фотошопе кнопку перекрасить из серого в красный) и это вызывает определенные сложности. Спасибо соседям по коворкингу, что выручают (Николай, Надежда — это я про вас ;).
В общем, если кто-то из программистов, читающих мой блог, бывал на таких курсах — был бы рад услышать про них отзыв: стоит или нет.
PPS: Если, вдруг, какой-то дизайнер забредет на мой программистский блог — буду рад возможности сотрудничества. Пишите в комментариях ;).
Проекты бывают разные. Некоторые можно сделать за два дня, некоторые за месяц, некоторые длятся годами. Именно про последние хотел написать эту заметку.
Дело в том, что общаясь в среде различных программистов с завидной периодичность наблюдаю следующую сцену. Один разработчик рассказывает и показывает итоги своей работы другим программистам в надежде получить отзыв вроде: «Ну ты крууууут!«, в ответ же он получает не возгласы восхищения и аплодисменты, а вопрос: «На что именно было потрачено столько времени? На ЭТО? Что тут такого делать, почему так долго?«. После этой фразы начинаются жаркие споры, обиды, непонимание и обвинения в некомпетентности друг друга.
Хорошо когда такие беседы проходят в дружеской программисткой атмосфере. Гораздо сложнее, когда выяснение отношений происходит на другом уровне. Например, когда одна команда пытается подрезать заказ у другой, убеждая клиента в том, что если бы обратились к ним, то они дескать сделали бы все гораздо быстрее и без затягивания сроков. Что принятые решения изначально были нерациональными и т.д.
Более того, сами программисты спустя годы, оборачиваясь назад начинают думать: «Я потратил на это три/пять/семь лет своей жизни? Почему?! Как ЭТО заняло столько времени?»
Одной из причин, на мой взгляд, является не совсем точное представление о том, как оценивается сложность проекта. Для многих это прямая из точки А в точку B.
Пред глазами предстает следующая картинка.
На самом деле, это идеальная картина. В жизни разработка сложного проекта сопровождается решением многих неучтенных проблем. Возникают «развилки» на которых нужно принимать решение куда двигаться дальше. Это могут быть решения высокого уровня, такие как выбор языка (java, c#, python или всё вместе) или способ хранения данных (mysql, oracle, berkley db, mongodb, hazelcast или все вместе), так и более низкого уровня — какой веб-фреймворк выбрать (ext или gwt, или может быть JSF 2 и т.д.), прикрутить velocity или обойтись стандартными средствами для работы со строками, начать использовать более популярный graddle или остаться на maven-е (или даже ant-e), использовать AnglularJS или не стоит.
Таких «точек бифуркации» в большом проекте может быть несколько десятков или даже сотен. При этом важно понимать, что все могут ошибаться и иногда приходится возвращаться на исходную позицию, менять стратегию, платформу (или как говорят программисты «переписать половину кода»). Кроме этого цель из точки B может передвинуться в точку B’ и в результате некоторые принятые решения уже могут оказаться неподходящими.
Другими словами лучше описывает ситуацию следующая картина.
В итоге, полученное «дерево решений» получается довольно ветвистым, а его «построение» делается методом «разведки боем» и занимает уйму времени. При этом, когда человек уже находится в конечной точке B и если он не страдает потерей памяти, то скорее всего повторить этот путь ему будет намного проще. Он уже знает как добраться к цели, по каким именно дорогам идти и на каком перекрестке свернуть.
Конечно более сложный случай, когда нет хороших проторенных «дорог». Например, если это принципиально новая разработка. В таком случаях утверждение «Что он тут такого делает уже N-цатый год?«, звучит аналогично претензии к Колумбу: «Что тут такого? Здесь и ежу понятно, что нужно просто плыть на запад и попадешь в Америку«. Сегодня это кажется очевидным, а тогда найти средства на подобную авантюру было не так уж и просто. Опять-таки в итоге Колумб все-таки ошибся где-то в три с половиной раза (почти на Пи), ведь изначально он хотел попасть в Индию, а она намного дальше…
Возвращаясь в наши дни, к теме этой заметки, хотел подвести небольшое резюме.
Чтобы оценить сложность проекта нужно проделать большую работу (см. картинку с деревом решений). Не стоит прогибаться, когда заказчик требует выдать ему оценку сложности какого-то нового проекта в человеко-часах, суть которого вам изложили только что на словах в трех предложениях за чашечкой кофе. Реальная цена такой оценки наверное будет меньше стоимости выпитой вами чашки кофе.
Не стоит удивляться и сильно корить себя за количество потраченного времени. Во-первых в жизни часто сложности забываются, поэтому возникает кажущееся ощущение легкости пройденного пути, а во-вторых задним умом мы все гении.
Желательно искать хорошего «проводника», у которого был опыт работы если не в аналогичных, то хотя бы в похожих проектах. Естественно, что каждый проект в чем-то уникален, но возможно его интуиция и опыт позволит частично избежать попадания в тупиковые ситуации.
P.S. В качестве иллюстрации нарисовал дерево, на развилках которого выбирается один вариант и подсвечивается красным цветом. При нажатии мышкой на дерево, оно случайным образом перестраивается.
Приятного просмотра!
P.P.S. Дерево прорисовывается с помощью языка программирования processing. Собственно экспериментами с ним, а также arduino и raspberry pi сейчас посвящены воркшопы, которые мы проводим вместо проводимых ранее Scala-тусовок.
Так получилось, что я знаком со многими программистами, которые работают в крупных (и не очень) софтверных компаниях в качестве наемных сотрудников, т.е. на окладе. На сегодняшний день Москве можно наблюдать два явления:
1. Дефицит квалифицированных кадров.
2. Кризис самореализации. Много ИТ специалистов в прошлом учились в лучших высших учебных заведениях России, но текущая их работы не в полной мере позволяет им реализовать свой потенциал. Одни мирятся с таким положением дел, у других возникает желание «изменить судьбу», открыть свое дело, начать стартап, освободиться от «офисного рабства».
Как следствие они начинают карьеру молодого предпринимателя, пытаясь начать самостоятельные проекты, искать заказы на разработку ПО. При этом у многих сохраняются наивные представления о том, как продавать свои услуги, на каких условиях работать с клиентом и самый главный вопрос возникающий у начинающего московского программиста-предприниматели — сколько стоят его услуги по созданию программного обеспечения. Для многих технически подкованных специалистов моего возраста в школьные годы не составляла особого труда решить примера вида:
Пример из сборника задач Сканави М.И. для поступающих ВТУЗы. В прошлом, те кто хотел поступить в ВУЗ могли решить такой пример не особо себя утруждаю, как мы шутили «спинным мозгом». Наверное сейчас с появлением ЕГЭ эпоха задач из Сканави уходит в прошлое.
С другой стороны, когда нужно сделать не намного более сложные арифметические и алгебраические операции, но вместо конкретных чисел будут стоять налоги, накладные расходы, человеко-часы, риски, объемы, сроки, скидки и другие составляющие, то это вызывает панику. Человек с высшим техническим образованием может потратить несколько дней или даже недель, чтобы найти грубые ошибок в своих вычислениях.
Другими словами, если речь идёт о готовом математическом выражении — всё просто, но если это якобы «бизнес» ситуация и нужно ответить на вопрос «за 100 000 сделаешь программу?» или «сколько будет стоит сделать мобильное приложение?», то начинается тупёж. Например постоянно сталкиваюсь с людьми, которые путаются с процентами и не могут посчитать какую цену они должны указать заказчику, чтобы у них осталось 100 000 рублей после оплаты налога в 6% с дохода?
Казалось бы ответ очевиден — приблизительно 106 383 рубля, но даже в таком простом примере многие делают ошибки (считают 106 000) или вообще не учитывают налог в конечной стоимости («да ладно, пусть, чего мелочится, всего 6%»). Когда же нужно проделать более «сложные» вычисления, т.е. учесть в цене все затраты (часы на согласование проекта, тестирование, внедрение, отчисления в фонды, обслуживание счета в банке, расходы на аренду, обрудывание и другие расходы), то в итоге некоторые делают множество существенных арифметических, алгебраических и алгоритмических ошибок. Хотя на самом деле, здесь нет ничего сложного.
Ошибка 1.
Допустим существует некий абстрактный московский java-программист. Его зарплата 120 000 в месяц. Он решил, что начинает работать на себя. Какую стоимость человеко-часа выставлять заказчику? Берем зарплату и делим на среднее количество рабочих часов в месяц (допустим 164,17 часов). Получаем стоимость часа около 731 рубля.
Давайте приведем аналогию из сферы услуг. Я знаю фитнес-центр в котором годовой абонемент стоит 16 000 рублей. Это недорого для Москвы (даже скажем средний, бюджетный вариант). Фитнес открыт ежедневно, работает по 12 часов в день. Разделим 16 000 на количество часов в году (365 дней * 12 часов = 4 380 часов) и получим стоимость часа равную 3 рубля 65 копеек. Посчитав это, я решаю пойти и позаниматься 2 часа, т.к. по моим расчетам должен заплатить 7 руб 30 копеек. Вопрос, почему администрации фитнес-центра требует с меня за разовое посещение 500 руб?! Что за наглость?
2 * (16 000 / (365 * 12)) = 7.30 != 500
Устраиваясь на работу, программист предоставляет свои услуги работодателю не на один месяц, а как правило по бессрочному договору, т.е. работать будет годами (хотя на обычно специалист меняет работодателя через 2-5 лет). Вы как бы «продаете» годовой абонемент своему работодателю — будут для вас задачи или нет, это уже не ваши проблемы. Фитнес-центр же не виноват, что кому-то лень тащить свое тело в зал и кто-то не приходит заниматься уже вторую неделю. Так и здесь, работодатель сам должен обеспечить вам фронт работы, а вы качественно программировать и получать каждый месяц зарплату. Если задач нет, то можно плевать в потолок или гонять танки, вашей вины в простое нет.
Другими словами, если вам предлагают проект на условиях: 2 миллиона рублей на 12 человеко-месяцев, деньги поступают каждый месяц, заказчик покупает вам необходимую для работы компьютерную технику, оплачивает интернет и аренду рабочего места, то можно говорить о том, что стоимость часа равна 731 рублей. Если это подработка на 60-100 часов, то о каких 731 рублей за час может идти речь? Вас же за 7 рублей в фитнес-клуб никто не пустит, хотя стоимость часа рассчитана по схожему принципу. Думаю для любого торговца на улице очевидна причина в разнице цены за килограмм картошки между покупкой ее вагонами и трех килограммов в розницу, но почему-то у программистов-предпринимателей работает «линейное» мышление в расчете цены.
Ошибка 2.
Есть такой бородатый анекдот: Новый русский открыл фотосалон и дал объявление: «Приглашаю фотомодель для съемки. Оплата наличкой на месте. За час работы 20 тысяч баксов».
Набежала куча моделей, отобрали одну, снимали с вечера и до ночи.
Приходит новый русский:
— Ну что, фотограф, сколько наснимал?
— Четыреста кадров.
— А выдержку ставил какую?
— 1/200 секунды.
— Ну ты, девка, в натуре, на две секунды всего лишь наработала, держи 12 баксов.
К чему я вспомнил этот старый анекдот из прошедшей эпохи?
Важно! Все измышления и предположения отражают мое личное мнение и естественно могут не совпадать с мнением большинства, впрочем, как и другие аналогичные статьи.
Статья про рок-банды, новое время и программирование.
Давно хотел провести аналогию между музыкой и программированием. Например команда разрабатывающая большие и сложные системы чем-то похожа на симфонический оркестр:
Вначале гениальный композитор должен написать свое бессмертное произведение, затем талантливый дирижер согласиться его исполнить, а все участники оркестра должны под его чутким руководством выучить и отработать необходимый материал. Итог работы будет зависеть от каждого участника (естественно в разной степени, никого не хочу обидеть, но вклад первой скрипки и парня с тарелками в заднем ряду сильно отличается).
Если мы посмотрим на разработку программных продуктов по классической водопадной схеме, то состав участников также будет довольно обширным: архитектор, тим лид, ведущие программисты, несколько программистов разной специализации (java, c/с++, javascript и тд) и группа дизайнеров с верстальщиками. Естественно далеко не все компании могут себе позволить идеально укомплектованный состав. Наиболее успешные организации могут заинтересовать в профессиональном и материальном плане более сильных специалистов, остальные конторы довольствуются тем, кто соответствует их уровню.
Тем не менее, на мой взгляд, существуют предпосылки для все большей популяризации нового формата коллективов. Во-первых это связано с большей доступностью компьютерной техники и развитием сервисов для разработчиков, во-вторых с ростом среднего уровня компьютерной грамотности, в-третьих формирование более позитивного отношения к техногикам у молодежи и общества в целом (сериал Теория Большого Взрыва, истории успеха и биографии Билла Гейтса, Марка Цукерберга, Стива Джобса и тд).
Под новым форматом я имею в виду небольшой творческий коллективов состоящий из 3-5 человек. Это еще не «оркестр», но уже и не соло-программист. Естественно масштаб создаваемых произведений не сопоставим с творением Классики. Другими словами, если проводить аналогии, речь идет о коллективах создающие программы «по духу» более близкие к Yesterday Битлз, чем к Хорошо темперированному клавиру И.С. Баха.
Все идет к тому, что в программировании наступит время аналогичное музыкальной эпохи 60-70гг прошлого века.
У кого-то может возникнуть такая ассоциация:
у других такая:
Давно уже ничего не писал на общие темы — о выборе профессии, жизненном пути или поиске предназначения. Последний раз подобных тем касался почти три года назад.
Прежде чем начать изложение, хотел сообщить, что я осознаю всю нестрогость моих расчетов и надеюсь никто не станет воспринимать приведенные ниже доводы буквально!
Теперь можно приступать.
Думаю многие знают о происхождении слова талант. Если кто не знает и есть желание подробно изучить этот вопрос, то привожу ссылку на соответствующую статью в википедии. В кратком изложении вся история с талантом выглядит следующим образом.
Талант, в современном понимании, это определённые способности, которые раскрываются с приобретением навыка и опыта. Поиск источника такого толкования этого слова приведет нас к притче о талантах.
В древнем мире талант был мерой веса. В той притче некий хозяин раздал своим рабам несколько талантов золота. Одному дал пять, другом два, третьему один. Затем отлучился на некоторое время. Когда вернулся стал выяснять кто что сделал.
Один приумножил, второй разменял, а третий закопал свой талант в землю. Того, кто закопал, хозяин отругал, других похвалил и наградил. Мораль — закапывать свой талант плохо, приумножать — хорошо.
Недавно мне стало интересно, а сколько именно было закопано? Немного покопавшись в интернете нашел приближенные исходные данные и произвел следующий расчет.
Итак, 31 октября, накануне Хеллоуина я уехал из коворкинга.
В сумме провел в нем около 9 месяцев.
Причины отъезда
Во-первых, стало шумно. Появилось несколько новых соседей, которые много общаются по телефону (больше 50-70% моего времени пребывания).
Одного-двух говорливых соседей терпеть еще можно, можно было одеть наушники, сделать перерыв и пройти прогуляться и т.д.
Когда «говорунов» становится больше трех, коворкинг превращается в call-центр.
Коммерческим и бизнес-задачам (вроде «холодных» звонков, назначение встреч, раздача задач сотрудникам и т.д.) это особо не мешает, а вот творить становится сложнее. Поэтому если вернусь в коворкинг — буду искать стол с менее шумным окружением.
Во-вторых, скопилось много дел, которые нужно решить в ноябре-декабре и для которых пребывание в коворкинге было не обязательно.
В итоге мы решили, что в ноябре-декабре наша «команда программистов» вернётся к старому формату — работаем дома и встречаемся в кафешках. Как в старые добрые времена.
Впечатления
…I’m enjoying the casino business. You meet a lot of colorful characters… Donbot. Futurama (S07E11) Viva Mars Vegas!
В коворкинге можно встретить множество различных колоритных людей.
Наверное, если сделать такой прибор, который бы измерял плотность стартаперов (количество ген. директоров, деленное на квадратный метр), то именно в коворкинге он бы зашкаливал. Забавно, но когда постоянно находишься в окружении начинающих предпринимателей, кажется что вся Москва населена стартаперами.
Другой большой плюс, по сравнению с надомной работой, то что во Флаконе постоянно проводятся различные мероприятия.
Вот небольшой список запомнившихся мне событий.
День Испании. 28 Июля
http://www.youtube.com/watch?v=FYbSq1CSt1Y
День Кении. 7–9 Сентября
http://www.youtube.com/watch?v=rTIr1EGbqvw
Иногда проводятся разные бесплатные мастер-классы на территории завода. Например, мне запомнился мастер-класс по дизайну интерьера от британской школы. Лепили из бумаги разные скетчи. Вот что у меня получилось.
Еще проводился мастер-класс в магазинчике с маркерами. Вообще во Флаконе чего много, так это именно разных магазинчиков с молескинами, оригинальными футболками, сувенирами и прочей утварью.
Некоторые хинты
Парковка
Идеально приезжать в 7-8 утра. Ближе к обеду парковку найти сложнее, можно попытать счастья у АЗС-ки в тупике Новодмитровской у железнодорожного перехода.
Еда
Рядом есть хлебзавод. Утром продают неплохие пирожные. После обеда заходить нет смысла — ничего не остается.
Через Дмитровку — магазин с белорусскими товарами. Неплохие печенье и конфеты.
Обедал я , как правило, бизнес-ланчем в кафе Брокард на территории Флакона. Если много народу, лучше сразу уходить — обслуживание может сильно затянуться.
Интернет
Подключаться по шнурку. WiFi в час-пик тормозит.
Фитнес
В 15-20 минутах ходьбы находятся:
1. Бассейн с тренажерным залом (через Дмитровку).
2. Тренажерный зал, сауна (через железную дорогу).
P.S.: У администратора коворкинга попросил фоты помещения, как пришлет — выложу.
Прошел где-то месяц, с того момента как я переехал работать в коворкинг. В связи с этим хотел поделиться некоторыми итогами и своими впечатлениями.
В первую очередь, хотел ответить на вопрос, который задают в первую очередь: «Сколько стоит?».
Стоимость аренды около 10 тысяч рублей в месяц. Комментировать цену не хочу.
Подробнее можно прочитать на сайте: http://www.flacon.su/space/coworking/
Расположение.
Коворкинг на территории дизайн-завода «Флакон» (ул. Б. Новодмитровская, д. 36). Ближайшее метро — Дмитровская.
Прошло уже больше месяца, с тех пор как я обещал друзьям написать про свою поездку в Питер. Было очень много разных дел по работе, в итоге только сейчас смог дописать.
We use cookies on our website to give you the most relevant experience by remembering your preferences and repeat visits. By clicking “Accept All”, you consent to the use of ALL the cookies. However, you may visit "Cookie Settings" to provide a controlled consent.
This website uses cookies to improve your experience while you navigate through the website. Out of these, the cookies that are categorized as necessary are stored on your browser as they are essential for the working of basic functionalities of the website. We also use third-party cookies that help us analyze and understand how you use this website. These cookies will be stored in your browser only with your consent. You also have the option to opt-out of these cookies. But opting out of some of these cookies may affect your browsing experience.
Necessary cookies are absolutely essential for the website to function properly. These cookies ensure basic functionalities and security features of the website, anonymously.
Cookie
Duration
Description
cookielawinfo-checkbox-analytics
11 months
This cookie is set by GDPR Cookie Consent plugin. The cookie is used to store the user consent for the cookies in the category "Analytics".
cookielawinfo-checkbox-functional
11 months
The cookie is set by GDPR cookie consent to record the user consent for the cookies in the category "Functional".
cookielawinfo-checkbox-necessary
11 months
This cookie is set by GDPR Cookie Consent plugin. The cookies is used to store the user consent for the cookies in the category "Necessary".
cookielawinfo-checkbox-others
11 months
This cookie is set by GDPR Cookie Consent plugin. The cookie is used to store the user consent for the cookies in the category "Other.
cookielawinfo-checkbox-performance
11 months
This cookie is set by GDPR Cookie Consent plugin. The cookie is used to store the user consent for the cookies in the category "Performance".
viewed_cookie_policy
11 months
The cookie is set by the GDPR Cookie Consent plugin and is used to store whether or not user has consented to the use of cookies. It does not store any personal data.
Functional cookies help to perform certain functionalities like sharing the content of the website on social media platforms, collect feedbacks, and other third-party features.
Performance cookies are used to understand and analyze the key performance indexes of the website which helps in delivering a better user experience for the visitors.
Analytical cookies are used to understand how visitors interact with the website. These cookies help provide information on metrics the number of visitors, bounce rate, traffic source, etc.
Advertisement cookies are used to provide visitors with relevant ads and marketing campaigns. These cookies track visitors across websites and collect information to provide customized ads.