maximzasorin

У меня навенорное проклятие какое то. Спустя 2 года в гугле ищу такую же проблему но уже с AIR и попадаю на свой же вопрос…

1. Проводите на любом сервере (желательно с похожей софтовой конфигурацией) с нужной конфигурацией 5-10 тестов на эталонных данных: урлы, кол-во одновременных соединений с заранее известными входными параметрами (по периодичности запросов, типам и т.д.) под нагрузкой в течение продолжительного промежутка времени (~30 минут на каждый) и смотрите за памятью и загрузкой CPU.
2. После каждого теста - весь сайт заливаете с нуля: базу, файлы, чистите все кэши.
3. По полученным данным - аппроксимируете и составляете график роста потребления ресурсов при увеличении входной нагрузки.
4. После этого, на основе расчётных параметров по посещаемости (кол-во запросов в сутки), рассчитываете требуемую конфигурацию сервера (исходя из полученного графика, скорости одного потока CPU, кол-ва потоков CPU и среднего времени обработки публичного веб-запроса к ресурсу).

Таким образом, получите 80-85% точность от реальной.
Затем, прибавляете к этому запас по мощности в 33% (1/3) и получите искомую величину.

Использовать онлайн-кассы для приема платежей придется обязательно. Кроме того, потребуется потратиться на приобретение фискального накопителя (ФН). Для УСН ФН приобретается на 3 года. Каждые 3 года меняется. На время замены касса должна сниматься с учета в налоговой, после замены - снова ставиться на учет. Так же потребуется оператор фискальных данных, которому касса будет отправлять данные о каждой транзакции и параллельно слать эти же данные в налоговую.

При работе могут возникнуть следующие проблемы. Курс пейпал и ЦБ не совпадают и кроме того пейпал забирает свою комиссию за обслуживание. Поэтому, получив одну сумму на кошелек, вы сможете распорядиться лишь несколько меньшей суммой, а вывести на расчетный счет и того меньше. При камеральной проверке вашей декларации налоговик, сверяя данные с вашим расчетным счетом (а доступ сегодня у налоговой есть ко всем р/с) увидит странное расхождение сумм в декларации и прошедших по счету, что потребует дополнительных разъяснений.

Необходимость вбивать каждую транзакцию в книгу учета доходов и расходов для продавцов цифровых товаров может превратиться настоящий ад - если в день по сотне продаж, то придется тратить кучу времени на постоянное перепечатывание наименований товаров в КУДиР.

Кроме того, как уже указали выше - получать платежи сможете только от физлиц. В другом случае (от компаний) платеж не пройдет.

В такой ситуации было бы здорово, если бы кто-то из посредников (типа westernbid или seller-online) дополнил перечень своих услуг возможностью сотрудничества с ИП из РФ. В этом случае целый комок проблем отпал бы сам собой - расчеты между юрлицами и ИП (взаиморасчеты с использованием расчетных счетов) не требуют использования кассы и связанных с этим дополнительных неудобств.

Осталось найти такого посредника, кто работал бы по такой схеме (получение платежей на свои счета с последующим выводом средств на расчетный счет ИП). Это бы решило огромное количество проблем для ИП и дало бы возможность получить огромное количество новых клиентов в виде ИП для такого агрегатора. Обе стороны были бы в плюсе.

Если кто знает таких посредников, напишите, было бы очень интересно рассмотреть возможные варианты.

К задней или нижней стороне стола крепится решетка, к которой уже стяжками/клипсами можно цеплять провода и мелкие девайсы вроде адаптеров и сетевых фильтров.


www.instructables.com/id/Computer-desk-cable-management-on-the-cheap/?ALLSTEPS

.htaccess в каталогах (не нужны права рута) и простая возможность запускать разные сайты от разных пользователей. Вроде так.

А зачем хранить в единственном экземпляре большое количество фотографий? Я сам снимал раньше по 1000-2000 фоток за одно мероприятие. Хранил RAW. А потом понял, что хранить хлам мне неинтересно. Снимаю параллельно Jpeg/Raw, причём джыпеги маленькие. Стараюсь попадать сразу нормально в WB. Потом отсмотр обязательно на аппарате, убиваю неудачные дубли. Второй рейд — уже на компе. В итоге научился делать 100-150 фото вместо 1000-2000, а количество удачных кадров возросло. Опыт говорит о том, что реально с мероприятия интереснее иметь 12-36 крутых фотографий, аккуратно цветокорректированных из RAW и бережно почищенных Photoshop, чем куча серо-зелёного говна. Кто, когда, зачем будет смотреть эти унылые, тусклые потуги?

Я храню те RAW, которые ещё не чистил. И те, которые настолько нереально крутые, что я готов их отдавать в офсетную печать, на бигморды или печатать метро на два на холсте. Это я храню. Этого мало. Такого много не бывает.

В итоге: есть два файл-сервера разных производителей, дома и на работе. И там лежит архив. В каждой папке фотосессии три папки: все удачные маленькие нечищенные jpg минус почищенные, почищенные jpg и оставшиеся raw.

Те же фотографии, которые не стыдно показывать, то есть почищенные jpg, продублированы столько раз… На macbook, ipad, sony playstation, flikr, facebook. И ещё раз в год отписываю DVD. На 1-2 год влезает. CD-R, записанные в 1998 году читаются до сих пор, не погибло ни одного диска.

Мне кажется, что описанная автором поста проблема отнюдь не «железная», а философская. Нужно навести порядок в архивах. Нужно навести порядок в голове. Проблема с хранением файлов решится сама с собой. Рекомендую 100 фотографий ежегодно печатать в формате не меньше 10х15 и складывать в альбом. Совсем другие ощущения!

На истинность в последней инстанции не претендую. Это исключительно мой собственный личный опыт.

правильно было бы сформулировать вопрос так - чем ActiveRecord от DM отличается
DM:

AR:

Registry:

Лично я точный ответ дать затрудняюсь. Хотя и сам веб-программист почти 10 лет. Порой зависит от проекта. Один проект хочется делать и делать. Сначала делаешь на работе, задерживаясь на час-два в офисе, потом приходишь домой и поужинав до поздней ночи сидишь и делаешь его.
А порой, особенно если штамповка, даже пара часов работы уже вгоняет в уныние. Выручает при штамповке, как правило, отдельная доп оплата за каждый такой штамп. И тут уже интерес на штамповать побольше.

При сложном программировании первые пол часа-час вход в работу, далее 4-5 часов продуктивной работы далее 2-4 часа которые на следующий день сделаешь за 1час.
У меня както так.

Про тех кто работает по 10-16 часов. Такое рвение лет до 25, и то пока не женат, нет детей, родители живы и не болеют, и слава богу так сказать.

А потом:
Задерживаешься в течении недели на 3 часа на работе — ты мне изменяешь?! (говорит жена)
Задерживаешься на 2 часа и не забираешь ребенка из садика — да тебе наплевать на ребенка! (говорит жена) + п.1
Ты что не можешь отвезти детей в сад и школу? — вообще, ох#$%? — да тебе наплевать на детей! (говорит жена)
Как это мы не идёт в кино? — вообще, ох#$%? — да тебе наплевать на меня! (говорит жена)
Что значит ты устал, а я что просто так красное бельё одевала? + п.1
Вышел в субботу на работу и не отвез родителей на дачу — ты че, сынок, не уважаешь и не любишь родителей ?(говорят родители)
Ты занят в пятницу вечером… м-м и в субботу вечером!?!, да что ты за друг с тобой даже встретиться и оторваться некогда! в кого ты превратился (говорят друзья)

Не полный перечень вопросов, которые человек в возрасте ~30лет и лет 5 в браке, получает, если на работе что то проиходит не так.

1. Back-end с опытом фронтенда - это хорошо
2. Back-end оплачивается больше, сама сфера напорядок больше. У нас в компании разница в senior back/front правда небольшая - в 15-20%
3. Все таки это разные вещи, и творчество проявляешь по разному =)
Back-end это более хардкорная разработка) Для серьезных бородатых дядей) Например результат труда ты своего визуально не подкрепишь) Какая нибудь нетривиально анимированная SVGшка не будет радовать твой взор)
Но зато ты имеешь шанс получить кайф от того что написал какую нибудь автоматизированную интеграцию двух больших баз данных, или запилил нереально крутую архитектуру проекта =)

В общем на ЗП и условия не смотри - попытайся понять что тебе больше нравится =)
И если нет вариантов работать в текущей компании по интересному тебе направлению, если живешь в достаточно большом городе и выбор есть - то лучше смени место работы)

M в MVC — это доменная-модель. То есть набор классов, отвечающий за логику приложения.

В MVC модель - это как раз доменная сущность, с которой работает бизнес-логика (тоже относящаяся к части "Model"). Если же у вас есть необходимость как-то трансформировать/дополнять модель для передачи во View, то здесь и применяют т.н. ViewModels, на которые маппятся сущности.

MVC - это масштабируемый паттерн. Допустим, решение состоит из проектов:

• содержащего доменные сущности и бизнес-логику
  
• слой доступа к данным (DAL), который управляет хранением и передачей сущностей
  
• web-интерфейс (ASP.NET MVC-приложение)
  

Выходит, что наше MVC-приложение само по себе является лишь интерфейсом (View) всего проекта, хотя и содержит внутри MVC-фреймворк, свои внутренние модели (правильнее теперь их звать вью-модели), контроллеры и вью.