Обновить
102
0.2
Роман Смирнов@Source

Head of Elixir at Ecom.tech

Отправить сообщение

iirc, Smarty — это шаблонизатор, а не фреймворк.

Ну так, хотя бы помните, что это можно сделать… значит доку нагуглите за пару минут )

Тут спору нет, все люди разные и распределение квалификации очень широкое. Просто есть мнение, что Вам повезло, найти квалифицированного 1С-программиста не такая уж простая задача.

Вы невнимательно прочитали комментарий Falseclock… Цитирую:


Типичный пример. Мне надо было сделать интеграцию самописной CRM системой с 1С по REST\OData через HTTP-сервис, который появился недавно в платформе 1С.

Две недели упорного труда и сам реализовал то что мне нужно не имея никакого опыта программирования в 1С.

Я понял его мысль так, что бездумное использование CMS/CMF может довести уровень среднестатистического PHP-шника до уровня среднестатистического 1C-ника. Типа делай как в туториале и ни шагу в сторону.

А я верю Falseclock, приходилось несколько лет назад искать 1С-программиста… у них от словосочетания "HTTP-запрос" нервный тик начинается… и про то, что данные можно передавать не только через расшаренные XML-файлы, они даже слышать не хотят. Возможно есть исключения, но вживую не приходилось встречать.

Вопрос как удобнее во многом субъективен. Мне лично клавиатурный ввод нравится больше, т.к. сразу пропадают проблемы с распознаванием чужого почерка и повышается удобство редактирования(чтобы вписать пару слов не нужно стирать всю строку или впихивать галочками). А стрелочки и мышкой на ура рисуются.
Для тех, кто не любит клавиатуры, есть графические планшеты, по которым можно писать пером, гораздо удобнее чем маркером, т.к. писать ручкой привычно с детства, а маркер даёт избыточно толстую линию, да ещё и без возможности регулировать эту толщину.
Ещё есть обычные планшеты и touch-экраны, рисуйте по ним хоть пальцем, хоть стилусом. Кстати, онлайн-доски тоже на любой вкус есть, для любителей рукописного ввода может хватить чего-то типа AWW или WebWhiteboard. Конечно планшет или touch-экран для такого использованию будут необходимы, но это решаемо.
По большому счёту, для онлайн-обсуждений всё есть и со временем удобство будет только расти… На мой взгляд, реальные проблемы могут быть только из разряда фетишизма, ну типа вам хочется касаться доски, прёт от запаха маркера и его скрипа по доске и т.д.

Онлайн-доска — это тоже не проблема… Посмотрите RealtimeBoard и аналоги. Если уж по-честному, то они гораздо удобнее, чем обычные доски… площадь доски не заканчивается в самый неподходящий момент, никто не изрисует её случайно перманентным маркером, стикеры не отлетают, кол-во досок не ограничено и т.д.

Речь шла об общении с коллегами, а не с клиентами.

А вот общение по туманный перспективам, которые превратятся в эксперимент, а потом пойдут в продакшн — идет через Скайпы/Слэки крайне тяжело.

С чего вдруг? Если только вы привыкли жестами по туманным перспективам общаться, попутно дымя собеседнику в лицо… А вербальная информация нисколько не страдает от скайпов/слэков.
Переписка же ещё более мощный драйвер роста, удалённо Вы можете пообщаться практически с любым человеком в мире, а не ограничены уровнем сотрудников своей фирмы.

Сидючи в одном кабинете или встречаясь несколько раз в день — вы сможете прийти с консилиуму на пару порядков быстрее.

Справедливости ради, прийти можно к консенсусу, а консилиум можно собрать. Причём в IT его можно собрать по скайпу или любому аналогу для конференц-связи. Поэтому соглашусь, что Вы выдумывали себе несуществующую проблему.

не должен один человек писать и на sql, и на java, и на js, и на html, и на css

Почему нет? В крупных проектах с богатым фронтом будет конечно разделение по специализациям, но веб-студии из 2-3 программистов, про которые Вы упомянули, занимаются обычными типовыми сайтами. Глупо от них ожидать найма отдельного человека, который будет адаптировать шаблоны с TemplateMonster к хотелкам заказчика, и ещё одного человека для прикручивания плагинов к jQuery.

Мне на них тупо пофиг, если они не пытаются ко мне лезть.

Ни фига себе, двойные стандарты… Сами то предпочитаете именно лезть — отрывать от работы на мгновенную обратную связь. По факту мгновенная обратная связь нужна от силы пару раз в год.

Хм, тут проблема не в отвлекающем человеке, а в Вас… Как Вы предупредили, что работаете? закрыли межкомнатную дверь? поставили рядом с собой табличку "Work in progress"? или хотя бы на словах предупредили, что заняты работой? А учитывая, что Вы обычно ходите в офис, необходимость предупреждения возрастает раз в 100, по сравнению с ситуацией, когда Вы постоянно работаете из дома. А посылать людей за то, что они не имеют мощных экстрасенсорных способностей, действительно невежливо.

Наоборот, это ближе к традиционному формату школьных записочек… важное — запомнится, а неважное — прочитал и забыл.

Так формирование отчёта по уже выбранным данным не требует гигабайтов оперативки, если это не отчёт на несколько тысяч листов. SQL для того и существует, чтобы из БД только нужные для отчёта цифры достать. Или Вы имеете в виду, что можно косячно формировать отчёт, но вынести это в микросервис и уже будет не так заметно, что отчёт формируется чёрти как?

А я понял, Вы про роуты, которые для всех методов подходят. В таком случае в Rails будут просто игнориться все последующие дубликаты этого роута с указанием конкретного HTTP-метода. Хотя допускаю, что где-то роутинг может искать best match до победного конца, но имхо это странный вариант… first match будет всегда работать быстрее.

Да, я имел в виду случай, когда кронтаб формируется приложением, для вызова самого себя с определенными параметрами в определенное время.

Я не понимаю, почему у Вас каждый запрос обязательно добавляет N мегабайт…
Возможно, у Вас какие-то очень специфичные задачи… У меня график занятого ОЗУ в течении дня обычно больше похож на горизонтальную линию, при том, что максимальная нагрузка в 20 с лишним раз больше минимальной.

Линейный рост потребляемого ОЗУ это норма, а часто идеал, которого не могут достигнуть.

Т.е. у Вас по графику потребления ОЗУ на сервере можно сразу видеть, где были пиковые нагрузки? Ни CPU, ни Network I/O, а именно ОЗУ?


Грубо, если запрос пользователя обрабатывается 100 мс, то 16000 одновременных пользователей означает 160000 запросов в секунду — в каждый момент времени обрабатывается 16 000 запросов.

Такое количество запросов (популярность на уровне Twitter) никто в здравом уме не будет одним инстансом обрабатывать, т.е. как-то мимо начального вопроса получилось. На всю ферму серверов и 256 Gb нормально будет, а вот 16 Gb на один инстанс (а инстансов и на одном сервере может быть много) всё равно дичь получается.

Естественно сопоставление роутов идёт с учётом метода. Это не значит, что из-за этого проверять придётся все. Но в память загрузятся все — это да… несколько десятков килобайт займут )))

Информация

В рейтинге
2 993-й
Откуда
Россия
Работает в
Зарегистрирован
Активность