Пользуюсь таким больше года, замечательная вещь. Телефон заряжает быстро, выглядит хорошо. Самое то для дальних поездок.
Для повседневного ношения я бы взял версию поменьше, т.к. возможности 1.5-2 раза полностью зарядить телефон должно хватить на 24 часа с головой, а вес у старшего брата значительный.
Ещё пробовал заряжать планшет (Asus TF201, в комплекте идёт 2амперная зарядка), но не показывает процесс заряда, хотя выходной ток на аккумуляторе тоже указан 2А. Не разобрался в чём проблема, у вас так же?
Попробовал писать на Go несколько домашних поделок, на работе пишу на C#. Если вкратце, я пока так и не смог оценить преимуществ Go, кроме кросплатформенности:
Нет удобных средств для разработчика, IDE со встроенным дебаггером под винду так и не нашёл. Пользуюсь плагином для Idea
Каналы — удобно, но мне они нужны для параллельной обработки массивов данных. В C# это решается проще, Parallel.ForEach и вперёд
Очень непривычно создавать свои ненужные структуры для простой сортировки в Go. И в целом, LINQ для работы с коллекциями в разы удобнее. При работе с Go сильно не хватает
Зачастую, Go кажется слишком низкоуровневым, даже чрезмерно. В идеале, не хотел бы видеть в языке указатели без особой на то причины
Использовал библиотеку написанную на C++ в Go. Не скажу, что очень удобно, а, например, valgrind и вовсе не работает с такими приложениями. Встроенный отладчик память, выделенную в C++ коде, разумеется, не видит. И как отлаживать утечки?
В целом, язык интересный, но для себя достоинств я пока не увидел.
В Entity Framework 7 появилась возможность получать последовательные айдишники блоками по 10 штук (по умолчанию). Гарантируется, что все блоки не пересекаются, получение потокобезопасно и коллизий возникнуть не может.
С полученными блоками можно работать напрямую, явно указывая id при сохранении объекта.
Проблемы те же, что и в NHibernate — пропуски в id, быстрое увеличение значений ключа. По умолчанию по-прежнему ключ генерируется в БД.
Подробнее рассмотрено в видео блоге.
Если мы используем EntityFramework в нашем приложении, то одна их первых зависимостей, о которых мы задумаемся для использования DI – это DbContext. Это позволит нам написать менее завязанный на DbContext код, легче тестировать такой функционал и т.д.
А можете показать пример удобного тестирования при инжекте DbContext?
Я проверял публикацию БД на разных серверах как раз, видимо и SSDT обеспечить транзакционность не в состоянии, публиковать необходимо каждую базу отдельно.
Возможно, если БД на одном сервере, то и скрипт публикации будет один.
А как вы сейчас вносите согласованные изменения в разные БД на разных серверах?
Я тут подумал, что не знаю эффективного способа, желательно в одной транзакции.
Мы используем linked servera в разработке проектов. Зависимости между БД SSDT точно может отслеживать. Решается просто:
Добавить в solution все связанные БД.
Добавить переменную, которая будет ссылаться на linked сервер:
Аналогично добавить переменную, которая будет ссылаться на БД на этом сервере
Использовать в скриптах эти переменные:
SELECT
dbo.Customers.Id,
a.Id,
FROM dbo.Customers
LEFT OUTER JOIN [$(SrvSql1)].[$(Accounts)].dbo.account AS a ON dbo.Customers.Name = a.Name
При этом, если колонки a.Id в linked базе не будет, SSDT укажется на ошибку и не даст собрать проект
Более того, при изменении в одном месте с помощью рефакторинга, SSDT автоматически меняет ссылки во всех связанных базах, так что согласованные изменения также возможны.
Скорость рефакторинга проверить не могу, баз с десятками тысяч объектов нет.
6 терабайт важных данных для вас стоят меньше 45000 рублей? Тогда действительно нет смысла покупать, легче нанять человека на месяц, который всё восстановит вручную.
У вас действительно 6 терабайт невосстановимых данных? Не фильмов, популярной музыки, а документов, БД, личных фотографий и т.п?
Но разве вы не пишете код для того, чтобы решить какую-то проблему? Неважно что за задача, если вы её решаете за деньги, значит кому-то она настолько важна, что он готов заплатить.
Не из решения проблем ли состоит программирование, и только потом уже из кода?
А вот вы могли бы на пальцах объяснить, что такого делает VMProtect, что его настолько сложно взломать?
Ну то есть в программе всё равно где-то должна быть проверка вроде if (key.IsValid()), где можно всегда возвращать условный true.
Очевидно, что это не так, но в чём сложности и как именно запутывают не осознаю.
Выглядит интересно.
Есть (будут ли) какие-то автоматические способы перевода текущих приложений c ASP.NET MVC 5 на ASP.NET 5?
Или там и текущая реализация заведётся без проблем?
A mathematical model shows it would take longer than the universe has existed for room temperature cathedral glass to rearrange itself to appear melted.
Why old European glass is thicker at one end probably depends on how the glass was made. At that time, glassblowers created glass cylinders that were then flattened to make panes of glass. The resulting pieces may never have been uniformly flat and workers installing the windows preferred, for one reason or another, to put the thicker sides of the pane at the bottom. This gives them a melted look, but does not mean glass is a true liquid.
А именно:
Спасибо.
Для повседневного ношения я бы взял версию поменьше, т.к. возможности 1.5-2 раза полностью зарядить телефон должно хватить на 24 часа с головой, а вес у старшего брата значительный.
Ещё пробовал заряжать планшет (Asus TF201, в комплекте идёт 2амперная зарядка), но не показывает процесс заряда, хотя выходной ток на аккумуляторе тоже указан 2А. Не разобрался в чём проблема, у вас так же?
Попробовал писать на Go несколько домашних поделок, на работе пишу на C#. Если вкратце, я пока так и не смог оценить преимуществ Go, кроме кросплатформенности:
В целом, язык интересный, но для себя достоинств я пока не увидел.
С полученными блоками можно работать напрямую, явно указывая id при сохранении объекта.
Проблемы те же, что и в NHibernate — пропуски в id, быстрое увеличение значений ключа. По умолчанию по-прежнему ключ генерируется в БД.
Подробнее рассмотрено в видео блоге.
А можете показать пример удобного тестирования при инжекте DbContext?
Возможно, если БД на одном сервере, то и скрипт публикации будет один.
Я тут подумал, что не знаю эффективного способа, желательно в одной транзакции.
Более того, при изменении в одном месте с помощью рефакторинга, SSDT автоматически меняет ссылки во всех связанных базах, так что согласованные изменения также возможны.
Скорость рефакторинга проверить не могу, баз с десятками тысяч объектов нет.
Не из решения проблем ли состоит программирование, и только потом уже из кода?
Ну то есть в программе всё равно где-то должна быть проверка вроде if (key.IsValid()), где можно всегда возвращать условный true.
Очевидно, что это не так, но в чём сложности и как именно запутывают не осознаю.
Есть (будут ли) какие-то автоматические способы перевода текущих приложений c ASP.NET MVC 5 на ASP.NET 5?
Или там и текущая реализация заведётся без проблем?