Имхо, лучше от этого не становится. Особенно если учитывать тот факт, что какая-то информация хранится 3 года, при этом информация о соединениях может быть разной, скорее всего это информация типа подключение от узла А к узлу Б, (и если узел Б не в РФ, то на этом все обрывается) или же Вася скачал в полночь 2 Гб данных. То в данной новости сказано именно о действиях пользователя и о 6 месяцах, что скорее всего означает куда больший объем данных, чем просто информация о соединении.
Ну и в конце концов в документе речь об операторах связи. В ленте в том числе разговор идет про сайты.
Помимо ограничения максимальной суммы переводов авторы законопроекта внесли на рассмотрение еще ряд мер, ужесточающих контроль за происходящим в интернете. К ним, помимо прочего, относится предложение обязать интернет-ресурсы и провайдеров хранить в течение полугода данные обо всех действиях пользователей. За нарушение закона предусмотрены крупные штрафы.
чуть выше добавил про язык. у меня нет проблем, что основная часть информации на английском, я даже этому рад. Только это все равно официальная и сухая документация с упором на уже какие-то конкретные знания.
С SE мне полностью хватило за глаза и за уши оракла и overapi.com
Только вот SE это несколько другая штука ведь — она сильно переплетена с общими знаниями программирования, где все практически ясно, нужно лишь узнать как это устроено в Java
в моем сообщении язык ресурсов скорее влияет на «скорость» входа и удобство.
Толковый разработчик рано или поздно «войдет», если ему это надо.
Тех, кто только начинает или переходит, это очень сильно тормозит и оставляет скорее негативную оценку сообществу, чем положительную.
Вполне возможно, что стало хуже, т.к. Java так или иначе набирает популярность, а порог вхождения в EE довольно высок и вроде не снижается.
Могу судить по себе. Не считаю себя гуру программирования, но знаю, как мне кажется, достаточно, причем я довольно поздно начал пользоваться фреймворками (php) и если пользуюсь, то стараюсь понять как именно они работают и это не особо составляет труда.
В сентябре у меня начался курс по Java SE. Я довольно быстро его закрыл за счет общей подготовки, ничего особенно сложного я не заметил, хотя и сильно далеко не вникал. И вот настал момент, когда я вдруг решился взяться за Java EE, думал общее понимание мне поможет. Но блин, может я конечно ноль в программировании, но переход с php на Java EE мне пока не поддался полностью и продолжает сопротивляться.
Основная проблема в том, что по Java EE недостаточно толковых ресурсов на русском языке, даже на хабре информации маловато будет. Вся другая информация только на английском, что в принципе проблем особо не вызывает, но она написана настолько сухо, что иногда создается впечатление, что такие понятия как POJO, DAO, контексты, Bean, EJB, Сервлеты, Гризли, Мавены, Хероку, JDO, JPA и кучка других сокращений/названий, читающий априори знать обязан. Для начального уровня это очень трудно для восприятия, хотя понятно, что нужно иметь общее понятие о Java EE и без него никак. Но с названиями перебор. В итоге очень много времени тратишь на то, чтобы понять, надо ли оно тебе или это какая-то специфичная штука. Понадобилось JSON в Jersey — вот тебе MOXy, Jettison, Jackson. И так довольно часто, создается впечатление, что все это фреймворки, сделанные на фреймворках, чтобы создавать фреймворки.
Буду очень благодарен, если посоветуете какие-нибудь толковые ресурсы по Java EE. Пока что самым информативными для меня оказались туториалы от 308tube (про Jersey на youtube), но там порой совсем очевидные вещи проскакивают, хабр, stackoverflow и одностраничные документации, по которым удобно просто искать.
Потенциально опасный с моей точки зрения прогноз, поэтому скрою его под спойлер.
клац
В 2014 году у PHP нет будущего :)
Ну а вообще, как мне кажется, Laravel отхватит какой-нибудь огромный кусок/перехватит разработчиков из другого фреймворка + появится какой-нибудь переходный продукт между простыми магазинами и битриксом.
почему вы рассматриваете gps-трекеры только в качестве влепления ускорителя, а не в качестве выявления виновного в задержке? по треку явно можно определить на каком участке пути произошла задержка.
такая же ситуация с наклейками. при сортировке и передаче между разными пунктами (сортировка, насколько я понимаю, не ручная у нас) — делать снимок стикера в момент сортировки и заносить его в базу (все делается автоматом, на линии сортировки). получатель получил красный стикер — смотрим фотки, выявляем виновного, взимаем с него оплату, которую выплатили отправителю. все. просто уж лучше хоть что-нибудь для улучшения ситуации, чем не делать ничего вообще.
ну слушайте, я же не предлагаю таймеры времени доставки ставить :)
тем более, что если таки начнут передавать часть посылок на доставку через частные компании, то почему бы их не снабжать такими стикерами. Таким образом, обычная почта, как обычно, сможет снять с себя все претензии, а с частников спрашивать по всей строгости, ибо портят «репутацию почты», хотя куда уж хуже..)
ну вы утрируете. достаточно обязать как минимум все ценные/хрупкие/чувствительные к перегрузкам посылки снабжать подобным индикатором в момент отправки из почтового отделения и в момент получения показывать его принимающей стороне. если индикатор красный — возврат денег за пересылку и дальше определять степень ущерба.
тут в основном проблема будет с желанием отклеить подобную наклейку и наклеить новую, но, думаю, это решается наклейками с уникальным номером/qr-кодом и сообщением данного номера получателю :)
как только частота подобных выплат будет зашкаливать — начнут следить пристальнее за качеством, как мне кажется.
Ну и в конце концов в документе речь об операторах связи. В ленте в том числе разговор идет про сайты.
lenta.ru/news/2014/01/15/duma1/
С SE мне полностью хватило за глаза и за уши оракла и overapi.com
Только вот SE это несколько другая штука ведь — она сильно переплетена с общими знаниями программирования, где все практически ясно, нужно лишь узнать как это устроено в Java
в моем сообщении язык ресурсов скорее влияет на «скорость» входа и удобство.
Толковый разработчик рано или поздно «войдет», если ему это надо.
Тех, кто только начинает или переходит, это очень сильно тормозит и оставляет скорее негативную оценку сообществу, чем положительную.
Искусственный дефицит под личиной естественного отбора :)
Могу судить по себе. Не считаю себя гуру программирования, но знаю, как мне кажется, достаточно, причем я довольно поздно начал пользоваться фреймворками (php) и если пользуюсь, то стараюсь понять как именно они работают и это не особо составляет труда.
В сентябре у меня начался курс по Java SE. Я довольно быстро его закрыл за счет общей подготовки, ничего особенно сложного я не заметил, хотя и сильно далеко не вникал. И вот настал момент, когда я вдруг решился взяться за Java EE, думал общее понимание мне поможет. Но блин, может я конечно ноль в программировании, но переход с php на Java EE мне пока не поддался полностью и продолжает сопротивляться.
Основная проблема в том, что по Java EE недостаточно толковых ресурсов на русском языке, даже на хабре информации маловато будет. Вся другая информация только на английском, что в принципе проблем особо не вызывает, но она написана настолько сухо, что иногда создается впечатление, что такие понятия как POJO, DAO, контексты, Bean, EJB, Сервлеты, Гризли, Мавены, Хероку, JDO, JPA и кучка других сокращений/названий, читающий априори знать обязан. Для начального уровня это очень трудно для восприятия, хотя понятно, что нужно иметь общее понятие о Java EE и без него никак. Но с названиями перебор. В итоге очень много времени тратишь на то, чтобы понять, надо ли оно тебе или это какая-то специфичная штука. Понадобилось JSON в Jersey — вот тебе MOXy, Jettison, Jackson. И так довольно часто, создается впечатление, что все это фреймворки, сделанные на фреймворках, чтобы создавать фреймворки.
Буду очень благодарен, если посоветуете какие-нибудь толковые ресурсы по Java EE. Пока что самым информативными для меня оказались туториалы от 308tube (про Jersey на youtube), но там порой совсем очевидные вещи проскакивают, хабр, stackoverflow и одностраничные документации, по которым удобно просто искать.
Twitter
Reddit
Habrahabr.ru
StackOverflow
Planet-PHP
via blog.ircmaxell.com/2013/12/2013-year-in-review.html :)
обойти стек — суровое достижение, имхо)
Ну а вообще, как мне кажется, Laravel отхватит какой-нибудь огромный кусок/перехватит разработчиков из другого фреймворка + появится какой-нибудь переходный продукт между простыми магазинами и битриксом.
Речь о манекенах, конечно… как здесь, например:
угадал?)
такая же ситуация с наклейками. при сортировке и передаче между разными пунктами (сортировка, насколько я понимаю, не ручная у нас) — делать снимок стикера в момент сортировки и заносить его в базу (все делается автоматом, на линии сортировки). получатель получил красный стикер — смотрим фотки, выявляем виновного, взимаем с него оплату, которую выплатили отправителю. все. просто уж лучше хоть что-нибудь для улучшения ситуации, чем не делать ничего вообще.
тем более, что если таки начнут передавать часть посылок на доставку через частные компании, то почему бы их не снабжать такими стикерами. Таким образом, обычная почта, как обычно, сможет снять с себя все претензии, а с частников спрашивать по всей строгости, ибо портят «репутацию почты», хотя куда уж хуже..)
тут в основном проблема будет с желанием отклеить подобную наклейку и наклеить новую, но, думаю, это решается наклейками с уникальным номером/qr-кодом и сообщением данного номера получателю :)
как только частота подобных выплат будет зашкаливать — начнут следить пристальнее за качеством, как мне кажется.