Adamos

Самое сложное во фрилансе, не языки и технологии.

• Умение продавать себя в толпе конкурентов. Это самое сложное. Есть много высококлассных специалистов, сидящих на среднем окладе. Они тупо не могут себя продать даже в другую компанию, а не редко и боятся менять привычное место.
  
• Умение грамотно составить или согласовать ТЗ. Так что бы проблема заказчика решалась в оговоренные сроки и бюджет. А не перерастала в вечнострой с кучей доделок и переделок с базовым бюджетом. Когда обе стороны уже ненавидят друг друга. Ибо работая в офисе разработчиком, всё это ведут менеджеры и тим лиды, а вам спускают конкретные задачи. Вам же придётся научиться понимать, что хочет клиент, не разбирающийся в программировании, говоря то или это. Научиться понимать и предлагать те решения, которые будут ему актуальны с учётом технологий и отказывать в том, что сделать не реально. Находить компромиссы, но опять же, объясняя почему так или иначе.
  

Самое лучшее для фрилансера, да и любого разработчика. Это большие и долгие проекты. Когда можно постоянно заниматься одним. А не вникать каждый раз по новой, не привыкать к новому заказчику. Да, тут есть шанс отупения и застоя в развитии, но это лечится средними своими проектами или доп работой небольшой. Хотя, если проект живой и развивающейся, руководство ищет способы развития бизнеса и само заинтересованно в росте. Тогда можно и на текущем проекте развиваться, пробуя новые технологии, службы, стеки. Это будет рост как специалиста.

А технологии, языки. Это уже второстепенно. Главное развиваться. Ибо в попсовом PHP можно делать большие проекты и быть специалистом с большой стоимостью часа или на редком python/java сидеть и быдлокодить мелочь за копейки. Главное не метаться, а развиваться и расти, беря более сложные и более длинные проекты. И брать их не с "поддержкой", а с возможностью постоянного развития. Задачи "в стол", не интересны. А вот задачи на перспективу, на развитие. Это уже интересно. Ибо "в стол" это как правило теория(придумали, сделали, забыли). А развивающиеся, это практика на реальных условиях, когда в процессе приходится много менять (менять бизнес модель, менять архитектуру из-за возросших нагрузок, менять технологии).

Преждевременная оптимизация — корень всех зол

С++ замечательный язык, да немного странный ....хорошо временами он очень странный, но ему как первопроходцу это простительно, особенно учитывая какие возможности он дает.
Но в 97% при разработке под android эти возможности вам не нужны.
да ... увы и ах, но это так, знание с++ вам слабо помогут в разработке под android до тех пор пока вы не освоили хотя бы на базовом уровне android sdk, вы просто не поймете когда вам действительно нужно ndk а когда накладные расходы будут выше чем скорость выполнения на java.

Я читал статью на хабре, про которую вы говорите ─ бред. Бред не go, с тем же успехом могло быть с++, но из за определенной желтизны статьи создается впечатление что go решение всех проблем ... не в коем случае не укор автору статьи, но мне кажется он просто захотел поиграться с новой технологией ) почитайте внимательно комментарии к статье, там как это часто бывает куда больше интересного ))

Sayber ⏰ по моему вы не внимательно читали ответ one pavel ваши примеры так раз серверных приложений. И таки да, go действительно только начинает развиваться, пускать его в продакшен довольно не осмотрительно, у android и так достаточно багов, чтобы без серьезной необходимости играться еще с новыми

Если кратко по вопросу c++ or go то однозначно c++/c

Если более практично .... Александр Василенко не страдайте фигней. У вас есть опыт тестирования, в мире android на первых порах он будет куда ценнее чем опыт с++. В большинстве проектов вы не встретите с++
Освойте базовые вещи для android, если география позволяет идите в офис, нет ищите удаленку/фриланс, потом уже поймете что вам нужно.

Используйте готовые решения. За вас уже давно это сделали, при чем очень хорошо.

https://github.com/yii2tech/ar-position Расширение написал Климов, один из главных ментейнеров Yii2.

Постарайтесь изучить расширение и понять, как там все устроено. Если что - пишите, подскажу.

С очень активно используется в embedded программировании: С проще чем С++. Для него проще написать компилятор. Ресурсы управляются вручную и их расход легче контролировать.

С++ очень зависит от качества оптимизатора в компиляторе. Если у вас хреновый компилятор, то для максимальной эффективности придётся писать на «устаревшем С с классами». А для всяких специфических железок компиляторы обычно хреновые.

Взгляните на стандартную библиотеку: она написана для использование в дико ограниченных условиях: все параметры и результат умещаются в регистрах (поэтому много указателей), никакого выделения памяти в функциях (поэтому куча функций вроде gmtime, и даже _s функции в С11 пишут в переданный объект). Это позволяет использовать С в системах реального времени без сильных ограничений на библиотеку и язык.

С и С++ занимают разные ниши и поэтому не могут заменить друг-друга.

1. Лучше всех с Outlook естественно работает родной Exchange. Но, есть варианты. Первое, что отвалится и придется искать ему замену - autodiscover. На линуксе необходимо будет настроить веб-сервер, который по запросу на autodiscover.domain.ru будет слать необходимый XML файл. С траблшутингом в этом случае не знаком, думаю, есть какая-то веб-морда для этого.

Есть готовые решения, например, Zimbra. Существуют в опен-сорсе и вцелом неплохи.

2. Да, можно будет связать. LDAP же универсален. Поддерживает ли он мобильные платформы, думаю, тоже да, правда, не знаю точно. В любом случае скорее всего придется это пилить.

3. Можно настроить симлинки на Samba. Для репликации можно посмотреть в интернете, что вас устроит. Есть платные решения. И снова, придется пилить!

4. Здесь вы перейдете на аналог. Есть варианты в виде VNC или запуска удаленного рабочего стола через X11 forwarding в SSH

5. Останется вопрос с сервером. Перевесить 1С на Линукс?

6. DHCP естественно есть. Микротик имхо с дхцп справляется на редкость медленно.

7. Да, всё есть, всё придется конфигурировать ручками

8. С принтерами в линукс у меня не сложилось, не могу подсказать. Особенно не радовали драйвера.

Вы должны еще десять раз подумать. Особенно если вы не знакомы с линукс на уровне, достаточном для выполнения задуманного.

Может, в конечном итоге купить новое на базе MS будет дешевле, чем ваши пляски с бубном неизвестное количество времени. А если учесть, что по незнанию вы можете и рабочие часы своим коллегам "загубить", компания может потерять еще больше. Надежный бекап или надежные помощники за спиной вам бы не помешали. Удачи.

БД и СУБД к ним как раз для такого и были разработаны - чтобы хранить данные. Вы не поверите, но данные они тоже хранят в файлах на жёстком диске. Зачем изобретать велосипед, когда есть уже готовый инструмент. Используйте СУБД и не заморачивайтесь по поводу нагрузки. Она будет в разы меньше, чем если вы будете городить всё в один файл напрямую.

1. Используете mPDF
2. Создаете html-код с данным о заказе, картинками печати и подписями (их можно расположить с "position:absolute", чтобы встали на нужные места)
3. Из html создаете pdf-файл:

$mpdf = new mPDF;
$mpdf->setBasePath("http://example.com");
$mpdf->WriteHTML($html);
$pdf = $mpdf->Output('', 'S');

setBasePath - устанавливает домен, относительно которого вставлены картинки в html (если у них относительные пути)

Репутация на тостере добавляет хорошие дела в христианскую карму, прану в буддийскую карму, и немного шевелит нейроны.
Многие с высоким вкладом на тостере просто пользуются ресурсом, потому что это тоже своего рода развлечение, но для самообразования более полезное чем сапер.
Любой, у кого вклад хотя бы 100-200, точно знает, что от рейтинга на тостере не зависит ничего, поэтому на самом деле вряд ли кто-то парится по серьезному.

Вот команда:
find . -name '*.gz' -exec gunzip {} \;