Автоматически вам никто ничего больше платить не будет.
Шевелить своей извилиной для этого нужно.
У меня по импортным заказах доходы поднялись ровно в 2 раза.
По российским я нагло (ибо имею импортных заказчиков и не боюсь потерять работу внутри страны) стал задирать цены.
Заказчики мелкие в РФ — отвалились, а кое-кто и раззорились.
Остальные поскрепели зубами — и согласились. А куда им деваться-то?
Квалифицированных специалистов больше не стало. Напротив — умные квалифицированные стали работать на запад преимущественно. На внутренние заказы затянуть их стало трудно.
В сфере ИТ основные затраты (если вы не хостер, не провайдер, не крупный интегратор) — зарплата.
Если вам её не повысили, то у экспортных компаний затраты ничуть не увеличились.
При том, что доходы у них возросли ровно в 2 раза (курс рубля к доллару, если вы про РФ).
Почему они не желают этими доходами делиться с вами — другой вопрос.
Видимо, потому, что вы продолжаете работать на них за те же деньги.
Вы сами согласны на это.
Деньги-то у них есть. И даже больше, чем раньше. (из за скачка курса доллара в 2 раза).
Анекдот по этому поводу из диких девяностых, когда вообще не платили людям, а они продолжали ходить на рабору:
Встретились два директора предприятий. Один другому говорит:
— Представь, я своим работягам уже полгода зарплату не плачу, а они все ходят на работу и ходят.
— Слушай, а если с них плату за вход брать?
Ну, будут расширяться, а на рынке голод на квалифицированые кадры, — вашего нового коллегу наймут уже подороже.
1. Время нужно много, чтобы заработало это. Не 1 и не 2.
2. Работать надо самим. Не ждать, не обвинять других. А начать работать сами.
На сегодня есть бонусы в ИТ:
в ряде случаев хостинги нужно размещать в РФ. развивай свой внутренний хостовый бизнес.
работать можно на экспорт, получать деньги, которые после конвертации в рубли стали в 2 раза больше. в частности, поэтому российский хостинг стал стоить дешевле западного. развивай свой внутренний хостовый бизнес.
для других сфер деятельности (ориентированных на экспорт) — аналогично.
импорт же (тупое потребление) — затруднен. это да.
некоего политико-экономического доминирования над производителями.
Доминирование над миром, а не над производителями.
Доминирование над производителями — это как раз из-за больших объемов.
Очень просто: когда в США не хватает денег — их просто «печатают».
После чего любая страна в мире радостно обменяет свой товар на эти свеженапечатанные «бумажки».
Ни одна другая страна так делать не сможет. Их деньги просто обесценятся мгновенно.
В США же просто «растет гос. долг», который возвращать никто никогда не планирует.
Что значит «заставить доказывать»?
Это гражданское судопроизводство — тут обе стороны должны доказывать.
Не надо тень на плетень наводить — при современном уровне автоматизации таможне вести по каждому человку точный учет не является никакой проблемой.
Что то доказывать придется только если на таможне БД накроется, ну побегайте 1 раз в 10 лет. Ничего страшного.
Ну то есть для вас важно минимизировать риски неполучения результата.
Нужно отдавать себе отчет, что при этом в денежном эквиваленте вы сильно переплачиваете. Так как исполнитель в этом случае тоже закладывает свои риски в стоимость работ, подробнее об этом написано тут: https://habrahabr.ru/post/315624/#comment_9952610
Но, фактически, лично для вас эта переплата является более рациональной, чем риск полной потери всех денег по проекту в случае его не выполнения.
Тоже разумно.
P.S.:
У меня вопрос (риторический) — где вы таких исполнителей берете, что так шугаетесь невыполнения взятых ими обязательств.
Были бы все заказчики квалифицированы — закупались бы на фриланс биржах напрямую, а не через прокладки.
Отнюдь, и не суть в этом.
Иногда (часто) заказчика не нужны риски.
Заказчикам нужен комфорт.
И чем крупнее проект — тем больше риски с фриленсерами.
Если заказчик сам управляет этими рисками, то есть сам возится с фриленсерами, ежедневно их контролируя — то так жить можно.
Если заказчик сам не желает этого делать — он просто платит больше тому, кто берет риски на себя — в фирму-прослойку. И тогда с конечными разработчиками сюсюкаются уже фирмы-прослойки. И заслужено получают за это свои деньги.
И чем заказчик крупнее (богаче, жирнее) — тем он больше имеет возможностей на кого-то переложить свои головняки и сосредоточиться на главном.
Для мелкобизнесменов разумеется, крайне выгодным является самому стать квалифицированным — это позволяет существенно экономить.
Даже более того, даже самому выполнять какие-то части проекта — это действительно крайне эффективно для заказчиков без денег.
Кстати вполне соотносится с 60-ти дневной задержкой по оплате оказанных услуг. Нет результата — за что платить?
На самом деле конечный покупатель платит за все это.
Всегда. Всегда платить покупатель. За все.
Это будет или предоплата, куда фактически заложена эта 60-ти дневная оплата пропитания разработчика (та минимальная цена, за которую еще разработчик может работать). А вторая часть оплаты — это уже чистая премия разработчику за счет заказчика, то есть речь не идет ни о какой экономии и самых дешевых разработчиках — это всего лишь самообман. Самыми дешевыми получаются только те, кому платят ежедневно.
Либо это будет просто завышенная оплата в конце — куда заложены все риски. А это очень большая переплата.
P.S.:
Работаю на фриленсе лет 13 уже.
Все риски всегда на заказчике, даже если заказчик думает, что он самый умный и платит только по факту.
Иначе я давным давно двинул бы кони.
Скидку заказчик получает только по предоплате. При постоплате заказчик получает наценку. Всегда.
Это жизненно необходимо для закрытия себя от рисков.
Это правда. Где-то до 5го (10го, 20го, нужное подставить) клиента, после чего встанет выбор — размещать резюме и начинать экстренно искать работу, снова занимать денег (хорошо если есть где) или переходить на питание духовной пищей (а если есть семья, то и их тоже на духовные харчи переводить). В этот момент как правило происходит прозрение
Сейчас дефицит квалифицированных ИТ кадров.
При этом кто-нибудь на ваш призыв, разумеется, откликнется.
А сделать что нибудь более-менее не тривиальное, в сроки и без косяков — таких спецов нужно искать и задачи у них расписаны на недели (в лучшем случае на недели; у меня, к примеру — на пару месяцев) вперед.
Минус, по большому счёту один — данные могут не поместиться в оперативку
Разные инструменты — разный способ работы с ними.
Не нужно пытаться работать с in-memory ровно так же как и с RDBMS.
Наоборот — тоже не нужно.
Примеры использования очень разных СУБД в одном проекте для очень разных подзадач. Тут вам и in-memory и документарно-ориентированные и Cassandra-подобные с MapReduce…
https://habrahabr.ru/company/targetix/blog/266009/
https://habrahabr.ru/company/dca/blog/260845/
Способы обойти ограничения по памяти, если уж так прям край как надо именно in-memory СУБД, имеются.
Можно разделить данные по разным серверам — шардинг.
Можно использовать в Tarantool движок vinyl (в прежних версия sphia), а не движок memx, который включен в Tarantool по умолчанию — данные не обязаны помещаться в оперативную память. Правда vinyl/sphia это append only.
Сейчас Mail.ru проводит эксперименты по использованию vinyl в Tarantool для поиска по письмам. Речь идет о пентабайтах данных. Понятно, что это уже не чистая in-memory СУБД получается, но, возможно, для кого-то и такой способ использования окажется полезным.
Ну, хорошо, я считают, что держать маленькую highload БД на HDD — это извращение ;)
Думаю, Mail.Ru с их нагрузками делают это вовсе не потому, что они представители ЛГБТ или у них денег нет на диски (тем более, что всего-то речь идет о каких-то 8-ми серверах).
А потому что провели замеры и убедились, что на линейном чтении/записи никакой необходимости в SSD нет, а места для множества журналов WAL на HDD все же побольше/подешевле.
В нашем доме управляющие компании уже пару раз за последние лет 5 пинком под зад отправляли.
Шевелить своей извилиной для этого нужно.
У меня по импортным заказах доходы поднялись ровно в 2 раза.
По российским я нагло (ибо имею импортных заказчиков и не боюсь потерять работу внутри страны) стал задирать цены.
Заказчики мелкие в РФ — отвалились, а кое-кто и раззорились.
Остальные поскрепели зубами — и согласились. А куда им деваться-то?
Квалифицированных специалистов больше не стало. Напротив — умные квалифицированные стали работать на запад преимущественно. На внутренние заказы затянуть их стало трудно.
В сфере ИТ основные затраты (если вы не хостер, не провайдер, не крупный интегратор) — зарплата.
Если вам её не повысили, то у экспортных компаний затраты ничуть не увеличились.
При том, что доходы у них возросли ровно в 2 раза (курс рубля к доллару, если вы про РФ).
Почему они не желают этими доходами делиться с вами — другой вопрос.
Видимо, потому, что вы продолжаете работать на них за те же деньги.
Вы сами согласны на это.
Деньги-то у них есть. И даже больше, чем раньше. (из за скачка курса доллара в 2 раза).
Анекдот по этому поводу из диких девяностых, когда вообще не платили людям, а они продолжали ходить на рабору:
Ну, будут расширяться, а на рынке голод на квалифицированые кадры, — вашего нового коллегу наймут уже подороже.
Но это не будет основанием повысить зарплату вам.
1. Время нужно много, чтобы заработало это. Не 1 и не 2.
2. Работать надо самим. Не ждать, не обвинять других. А начать работать сами.
На сегодня есть бонусы в ИТ:
в ряде случаев хостинги нужно размещать в РФ. развивай свой внутренний хостовый бизнес.
работать можно на экспорт, получать деньги, которые после конвертации в рубли стали в 2 раза больше. в частности, поэтому российский хостинг стал стоить дешевле западного. развивай свой внутренний хостовый бизнес.
для других сфер деятельности (ориентированных на экспорт) — аналогично.
импорт же (тупое потребление) — затруднен. это да.
Когда эти «легкие кредиты» за дома простые американцы не смогли выплатить лет 8 назад — стартовал ипотечный кризис в США. А потом начался общемировой (почему-то) кризис.
https://ru.wikipedia.org/wiki/%D0%A4%D0%B8%D0%BD%D0%B0%D0%BD%D1%81%D0%BE%D0%B2%D1%8B%D0%B9_%D0%BA%D1%80%D0%B8%D0%B7%D0%B8%D1%81_2007%E2%80%942008_%D0%B3%D0%BE%D0%B4%D0%BE%D0%B2
Доминирование над миром, а не над производителями.
Доминирование над производителями — это как раз из-за больших объемов.
Очень просто: когда в США не хватает денег — их просто «печатают».
После чего любая страна в мире радостно обменяет свой товар на эти свеженапечатанные «бумажки».
Ни одна другая страна так делать не сможет. Их деньги просто обесценятся мгновенно.
В США же просто «растет гос. долг», который возвращать никто никогда не планирует.
Это гражданское судопроизводство — тут обе стороны должны доказывать.
Не надо тень на плетень наводить — при современном уровне автоматизации таможне вести по каждому человку точный учет не является никакой проблемой.
Что то доказывать придется только если на таможне БД накроется, ну побегайте 1 раз в 10 лет. Ничего страшного.
Нужно отдавать себе отчет, что при этом в денежном эквиваленте вы сильно переплачиваете. Так как исполнитель в этом случае тоже закладывает свои риски в стоимость работ, подробнее об этом написано тут: https://habrahabr.ru/post/315624/#comment_9952610
Но, фактически, лично для вас эта переплата является более рациональной, чем риск полной потери всех денег по проекту в случае его не выполнения.
Тоже разумно.
P.S.:
У меня вопрос (риторический) — где вы таких исполнителей берете, что так шугаетесь невыполнения взятых ими обязательств.
Если вы работаете с заказчиками напрямую — то выяснять ТЗ и объяснять как внедрять — это часть вашей работы.
Квалификация заказчика тут ровным счетом не причем.
Он вас потому и нанял, что в этой сфере вы более квалифицированы, чем он.
Ваше дело — просто включить надбавку в счет за эту свою доп. работу.
Отнюдь, и не суть в этом.
Иногда (часто) заказчика не нужны риски.
Заказчикам нужен комфорт.
И чем крупнее проект — тем больше риски с фриленсерами.
Если заказчик сам управляет этими рисками, то есть сам возится с фриленсерами, ежедневно их контролируя — то так жить можно.
Если заказчик сам не желает этого делать — он просто платит больше тому, кто берет риски на себя — в фирму-прослойку. И тогда с конечными разработчиками сюсюкаются уже фирмы-прослойки. И заслужено получают за это свои деньги.
И чем заказчик крупнее (богаче, жирнее) — тем он больше имеет возможностей на кого-то переложить свои головняки и сосредоточиться на главном.
Для мелкобизнесменов разумеется, крайне выгодным является самому стать квалифицированным — это позволяет существенно экономить.
Даже более того, даже самому выполнять какие-то части проекта — это действительно крайне эффективно для заказчиков без денег.
На самом деле конечный покупатель платит за все это.
Всегда. Всегда платить покупатель. За все.
Это будет или предоплата, куда фактически заложена эта 60-ти дневная оплата пропитания разработчика (та минимальная цена, за которую еще разработчик может работать). А вторая часть оплаты — это уже чистая премия разработчику за счет заказчика, то есть речь не идет ни о какой экономии и самых дешевых разработчиках — это всего лишь самообман. Самыми дешевыми получаются только те, кому платят ежедневно.
Либо это будет просто завышенная оплата в конце — куда заложены все риски. А это очень большая переплата.
P.S.:
Работаю на фриленсе лет 13 уже.
Все риски всегда на заказчике, даже если заказчик думает, что он самый умный и платит только по факту.
Иначе я давным давно двинул бы кони.
Скидку заказчик получает только по предоплате. При постоплате заказчик получает наценку. Всегда.
Это жизненно необходимо для закрытия себя от рисков.
Сейчас дефицит квалифицированных ИТ кадров.
При этом кто-нибудь на ваш призыв, разумеется, откликнется.
А сделать что нибудь более-менее не тривиальное, в сроки и без косяков — таких спецов нужно искать и задачи у них расписаны на недели (в лучшем случае на недели; у меня, к примеру — на пару месяцев) вперед.
Это рядовая часть вашей работы.
Ровно такая же часть, как и умения «натянуть оператор на константу»
Если бы заказчик сам разбирался — он бы не платил вам как квалифицированному специалисту, а платил бы как… гм… уборщице, например.
Если вас напрягают такие заказчики — идите на крупную фирму и работайте через менеджеров-постановщиков задач, а не напрямую с клиентом.
Квалифицированный клиент:
А за что платить вам?
За погляд?
Ну это как раз хватит, чтобы хлеб был с солью.
Но без масла.
Возможно, на ваших конкретных задачах, можно и без ТЗ вполне.
Например, на мелких задачах.
Но, как правило, если для вас важно в том числе и сэкономить деньги — именно ТЗ как раз и позволяет вам это сделать.
Рабочая разогретая реплика содержит 100% данных.
Вторая реплика может при этом стартовать весьма и весьма неспешно — этого никто и не заметит.
Разные инструменты — разный способ работы с ними.
Не нужно пытаться работать с in-memory ровно так же как и с RDBMS.
Наоборот — тоже не нужно.
Примеры использования очень разных СУБД в одном проекте для очень разных подзадач. Тут вам и in-memory и документарно-ориентированные и Cassandra-подобные с MapReduce…
https://habrahabr.ru/company/targetix/blog/266009/
https://habrahabr.ru/company/dca/blog/260845/
Способы обойти ограничения по памяти, если уж так прям край как надо именно in-memory СУБД, имеются.
Можно разделить данные по разным серверам — шардинг.
Можно использовать в Tarantool движок vinyl (в прежних версия sphia), а не движок memx, который включен в Tarantool по умолчанию — данные не обязаны помещаться в оперативную память. Правда vinyl/sphia это append only.
Сейчас Mail.ru проводит эксперименты по использованию vinyl в Tarantool для поиска по письмам. Речь идет о пентабайтах данных. Понятно, что это уже не чистая in-memory СУБД получается, но, возможно, для кого-то и такой способ использования окажется полезным.
А RDBMS такие скорости не под силу.
И что?
Каждому инструменту — свое предназначение.
Гвозди отверткой забивать невозможно.
Зачем применять методики из одной (непохожей) СУБД, для СУБД другой?
Каждому инструменту — свой способ заточки.
В in-memory СУБД разогрев происходит автоматом при рестарте.
А чтобы не было простоев — просто используются сервера-реплики.
Один уже разогрет и работает, второй в этом момент рестартует.
Думаю, Mail.Ru с их нагрузками делают это вовсе не потому, что они представители ЛГБТ или у них денег нет на диски (тем более, что всего-то речь идет о каких-то 8-ми серверах).
А потому что провели замеры и убедились, что на линейном чтении/записи никакой необходимости в SSD нет, а места для множества журналов WAL на HDD все же побольше/подешевле.