Как бы, не совсем ) Мой текущий шустрый телефон на морозе просто тормозит, но пользоваться ещё можно, а у джаст5 тормоза ацкие. А вот например моя магнитола в машине вообще на морозе показывает одну и ту же печальную картинку. Что-то ваша теория про полупроводники явно не учитывает )
Пользовался похожим. Just5, только немного другой модели. Мне откровенно не понравился телефон, пришлось выкинуть в ведро. Софт-тач пластик — настоящий ужас. Однажды я уронил телефон на дорогу без асфальта, после чего телефон покрылся пылью которую невозможно отмыть. Через месяц ношения в сумке он стал совсем грязным как у бомжары, цвет стал тусклым. Тормозил телефон жутко, особенно на морозе. Очень рад, что избавился от него. И да, батарея держит долго )
Я три недели назад задал вопрос в форуме: почему при использовании G1GC вся память кончается через 5 минут, а при обычном SerialGC — всё нормально. Ссылка. Может кто-нибудь прояснит ситуацию. И зачем мне плагин для НетБинс, когда всё остальное не работает?
"...DB-persistence-платформы, в которых логика чтения/записи БД находилась в методах самих персистируемых классов, из-за чего они должны были наследоваться от специального класса типа какого-нибудь DBExternalizableObject. В последствии, «как известно», от этого отказались."
Не согласен, что отказались. С появлением скриптовых языков на Java машине у доменных объектов снова появляются методы типа «search», «save» и т.д. Посмотрите например Grails или Spring Roo. Т.е. в зависимости от подключаемого плагина доменные объекты втихоря приобретают много новых методов. И хотя я против такого «супер-быстро-гибкого» подхода, но тем не менее данный принцип, я считаю обрёл второе дыхание и активно популяризуется. Возможно благодаря тому, что наследоваться в данных случаях уже не всегда обязательно.
Было бы здорово, если схема оплаты потраченных ресурсов была бы не очень сложной. А ещё лучше несколько вариантов: анлим (трать сколько хочешь, но мощности предоставляются небольшие) и эластик (как везде). А то говорят, мол, выбирайте облачный хостинг и не думайте о железе. Только вот постоянно приходится думать о том, сколько там у меня раз приложение обратилось к диску, не многовато-ли.
А почему Java и SQL это старое ПО? А что тогда новое? NoSQL и node.js что-ли? Мне кажется если почитать фундаментальные книжки по SQL(например Дейта) или по языкам и компиляторам, то возникает вопрос какое ПО ещё старое. Правильнее было бы сказать «классическое ПО».
Правильно, ничто не мотивирует учавствовать в процессе лучше, чем сам процесс. А процессы все от сотрудников скрыты. В основном никто не знает даже зачем нужен их продукт, в чем его фишка, кто наши партнеры, кто наши заказчики, из чего складывается прибыль. Также неизвестна какая заработная плата у других сотрудников(специальный трюк рабовладения). Приходишь на работу, смотришь таски/баги, выбираешь, делаешь и уходишь. А если всё от тебя скрыто, то и тебе лучше всего не особо высовываться. Сидишь потихоньку, читаешь хабр. О том, что каждый сотрудник может подкинуть клевую идею для фирмы тут даже и речь не идёт.
«Никто не готов жертвовать чем-то сейчас» — так уж и никто ) Во-первых: финансирование никуда не девается. Надо платить зарплату, т.к. программисты хоть и партнеры, но основная доля все равно у инвестора или крыши там всякой, кто проталкивает проект. Те работники кто хочет сразу получать много, т.к. у него два кредита, квартиру снимает и т.д. согласен возможно не подойдут. Ещё не подойдут слишком глупые и те кто любит отдыхать на выходных и любители стабильного завтра. Во-вторых: не все измеряется процентами. Партнерство для программиста — отличный способ перейти с зарплаты ниже рыночной на выше рыночную. (И всего-то?). Нет. Есть плюсы: не обязательно постоянно ходить в офис, возможность устраивать выходные среди недели а работать в выходные(это обычно редко кому надо), возможность участвовать в принятии решений и найме(приглашении в партнеры) новых сотрудников на работу. А как же будет при этом координироваться команда программистов? Если один спит, другой ест, третий уехал на рыбалку? В этом и секрет — тут не нужно много программистов. На начальном этапе когда все собрались рискнуть — как известно нужно все поминимому. Если через год команда ни к чему не приходит — то значит проект провалился. Итак, 3 программиста, а время 1 год, зарплата 50т (по московским меркам). Получаем 50 * 3 * 12 = 1800. Итого получаем 3-х программистов-архитекторов, готовых рискнуть, которые не будут лениться и минимальные денежные риски в случае провала. Я как программист работал по похожей схеме год. Честно скажу стартап не взлетел. Но каждый делал все что мог, теперь у меня куча опыта и я верю, что эта схема работает. Нанимать сотрудников могут крупные компании с устоявшимся бизнесом, которые не поскупились нанять профессионала по управлению сотрудниками. А подход типа я бизнесмен, придумал стартап, щас найму программистов (или фрилансеров) скорее всего не сработает.
Крепостное право не отменили. Оно приобрело новую, более хитрую форму. Все вроде свободны, а добровольно идут работать на дядю. А проблема в том, что цели работодателя и сотрудника расходятся. Работодатель не может быть уверен в том, что сотрудник делает то, что ему надо. Он постоянно ставит сроки, требует отчеты о проделанной работе и т.д. Потому, что они не партнеры. Сотрудник боится делать рефакторинг потому, что это оттянет сроки. Да и зачем? Если через год-два уволится сам. Вот если бы все работали по партнерской схеме. Ну не все, а хотя бы те кто составляет ядро проекта. Архитектор, несколько программистов, бизнес аналитик, тестировщик, ну кто там еще… Вот. Я думаю необходимость в таких книгах как «Рефакторинг» вообще бы отпала. Все свой код по 10 раз в день рефакторили бы. А вдруг в коде ошибка и прибыль сорвется? Но нет, принято же именно нанять, не пригласить к парнтерству. И все эти злоебучие статьи про то как эффективно управлять программистами, что дело не в зарплате и т.д. У нас аджайл! У нас аджайл нахуй! У нас ВСЁЁЁЁЁ гибко, ну кроме 8 часового рабочего дня… гы… Пользуясь случаем хочу передать всем авторам таких статей — идите в жопу!
Не согласен, что отказались. С появлением скриптовых языков на Java машине у доменных объектов снова появляются методы типа «search», «save» и т.д. Посмотрите например Grails или Spring Roo. Т.е. в зависимости от подключаемого плагина доменные объекты втихоря приобретают много новых методов. И хотя я против такого «супер-быстро-гибкого» подхода, но тем не менее данный принцип, я считаю обрёл второе дыхание и активно популяризуется. Возможно благодаря тому, что наследоваться в данных случаях уже не всегда обязательно.