А где это имя хранить в вашей архитектуре?
На уровне БД машины и производители лежат в разных таблицах. Т.е. нужен будет джойн. В коде это, соответственно, 2 класса-сущности.
Как с помощью вашей библиотеки получить список список авто и связанных с ними производителей?
Как поддерживать консистентность данных при этом?
Вообще, не знаю, что за проекты у вас, но в большинстве проектов, использующих реляционные БД так или иначе возникают потребности в связях (не хранить же всё денормализированным).
ну, человек должен думать когда задает имена полям как в коде так и в структуре БД.
А если БД уже есть? И нужно пристроится к готовой БД. Колонку переименовать тоже не всегда можно. Не во всех же случаях ты и код пишешь, и БД проектируешь.
На счёт типизации — вы явно путаете слабую типизацию с динамической. Ну да ладно.
Поскольку то, как именуются поля в БД и поля объекта, для компьютера значения не имеет, то нет никаких причин чтобы они не совпадали.
Зато для компиляторов имеет значение, т.к. есть такая штука, как зарезервированные слова. Что, если уже есть готовая таблица, в которой колонка названа class или public?
клёвые штуки…
слаботипизированность
уж слабая типизация ничего, кроме головной боли, обычно не несёт.
В beta.17 вышли breaking change для синтаксиса ngFor.
Суть такова: теперь #foo всегда будет локальной ссылкой на элемент. var-биндинг исчез, вместо него теперь let-биндинг.
Теперь, вместо <div *ngFor="#item of items"> надо писать <div *ngFor="let item of items">.
Такой код:
<ul>
<li *ngFor="let item in items">{{item}}</li>
</ul>
В el-get намного больше готовых пакетов, он сам добавляет пути к пакету в load-path, так что достаточно только добавить (require 'package-name). Ну и ещё много полезных и удобных штук, который отсутствуют в стандартном package.el.
Ну это смотря для чего конфиг. Если настроить программу, у которой куча опций плагинов и др. возможностей — самое оно. Собственно, все современные редакторы кода построены по такому принципу. В мире nodejs тоже предпочтительнее использовать js-код, а не просто json. Банально уменьшает количество копипаста.
с ним становится почти невозможно работать из другого софта
Мы же про ОС говорим? И про всякие более-менее стандартные (не узкоспециализированные) программы. Зачем с конфигом программы работать из другого софта? Кому может понадобится конфиг, например, nginx'а кроме него самого?
Если же некие конфиги будут использоваться кучей программ, то да, нужно что-то статическое и со схемами. Но тут xml наверное будет получше, хотя зависит от задачи.
Ещё есть Tcl. Из коробки есть почти в любом дистре. Плюс, приятное дополнение в виде Tk.
А вот у луа проблемы в плане работы с ОС (всякие операции с файлами и т.д.). Всё-таки он позиционируется больше как встраиваемый язык, так что там нет богатой стандартной библиотеки и удобной системы пакетов.
JSON прекрасный формат, чтобы его и читать глазками и компиком.
Ага, особенно радует отсутствие комментов, один вид кавычек, необходимость эти кавычки ставить в ключе, отсутствие trailing comma (это когда нельзя делать так: [1, 2, 3,]), скудность типов, и ещё куча недостатков. Наличие попыток сделать свой формат на основе JSON или добавить ему костыли — лишнее тому подтверждение.
Если настройки сводятся к ключ-значение, то ini и подобные ему куда лучше. Если настройки начинают выходить за эти рамки, то по мне уж лучше писать конфиг на каком-то языке программирования, например lua или js.
Нектопост какой-то. Если и брать первую версию, то 1.5, там много хороших нововведений. Ну а по-хорошему, второй версией спокойно можно пользоваться уже сейчас. Лучше напишите, как мигрировать с 1-й на вторую.
Фреймворк фреймворку рознь. Питоновский фласк изучить можно за день-два. Но без реального опыта разработки на нём, знания самого фреймворка мало что дадут.
Ситуации тоже бывают разные. Например, уволился человек, который писал какую-то часть проекта или проект на фреймворке X. Нужно срочно найти замену. Никто не станет рисковать, и брать человека без опыта, лучше сразу найти знающего специалиста. Если же есть команда, но требуются лишние руки, то часто принимают людей даже без знания языка, лишь бы был обучаем. А в конце испытательного срока всё встанет на свои места.
это вполне естественный, хотя и глубоко печальный факт.
Чем же он печален? Тем, что рутину теперь делают за тебя? Ну что же, инструменты развиваются в любой области. Раньше операции на глазах были практически невозможны, зато сейчас в любой клинике лазером могут подкорректировать зрение. Это тоже грустно?
Вот есть заказ на проект, с заранее оговоренной суммой. Основное требование — надёжность, на скорость по большей части плевать.
Вася пишет на скучной джаве, у него память сама подчищается, ошибки отлавливаются, а времени он тратит на всё это немного, так что успевает спать по ночам. Проект он сдаст через месяц, а потом поедет отдыхать.
А вот Петя пишет на интересном C, у него насыщенная жизнь: нужно постоянно следить за ресурсами, освобождать память вручную, следить за указателями, чтобы за диапазон не вышли. Он вручную анализирует ошибки по их кодам, стектрейсы составляет сам и все ночи сидит в дебаггере. Через полгода он ещё возится, деньги уже кончаются (полгода ведь надо что-то есть и где-то жить).
gmail offline? Да и разговор был о том, что сокращается функционал браузера. Ведь функциональность браузера — это ещё и его апи, позволяющее писать что-то для него. Так что если сравнить, что можно было сделать в браузере с расширениями/приложениями раньше и сейчас — то разница будет разительная. Достаточно посмотреть на приложения в магазине хрома. Да, в старую оперу встроили кучу сопутствующих приложений. А сейчас они просто ставятся отдельно.
Сейчас, например, в моём браузере есть табличный и текстовый процессор, редактор презентаций (и они работают офлайн). Было ли что-то подобное в старых браузерах или среди дополнений для них?
И что, много ваших патчей отклонили?
Вот смотрю я на популярные проекты, их issues. Очень много issues, которые заводят, не баги продукта, а не умение людей правильно пользоваться этим продуктом. Соответственно, пулл-реквесты и патчи тоже порой шлют такие, что лучше бы не высылали.
Форк же (если он качественный), сможет сдвинуть с мёртвой точки продукт (см. nodejs и io.js).
Удобно всё валить на систему, корпорации и бизнес. Вот только если у человека есть амбиции и навыки, он найдёт как выделиться, особенно в наше время. Самый банальный способ: завести проект на гитхабе.
Есть язык erlang. сложный. На нем ничего не написано.
«Эрланг учится за две недели, за год можно выучить до 26 эрлангов.»
Написано на нём довольно много. Всё работает обычно 24/7, его для этих целей и создавали.
Ну и так по каждому пункту. Если уж писать аналогии, то более честные.
Как минимум, python
Оно и видно по http://zippy.com.ua/
А где это имя хранить в вашей архитектуре?
На уровне БД машины и производители лежат в разных таблицах. Т.е. нужен будет джойн. В коде это, соответственно, 2 класса-сущности.
Как с помощью вашей библиотеки получить список список авто и связанных с ними производителей?
Как поддерживать консистентность данных при этом?
Вообще, не знаю, что за проекты у вас, но в большинстве проектов, использующих реляционные БД так или иначе возникают потребности в связях (не хранить же всё денормализированным).
А если БД уже есть? И нужно пристроится к готовой БД. Колонку переименовать тоже не всегда можно. Не во всех же случаях ты и код пишешь, и БД проектируешь.
На счёт типизации — вы явно путаете слабую типизацию с динамической. Ну да ладно.
Зато для компиляторов имеет значение, т.к. есть такая штука, как зарезервированные слова. Что, если уже есть готовая таблица, в которой колонка названа
classилиpublic?уж слабая типизация ничего, кроме головной боли, обычно не несёт.
В beta.17 вышли breaking change для синтаксиса ngFor.
Суть такова: теперь #foo всегда будет локальной ссылкой на элемент. var-биндинг исчез, вместо него теперь let-биндинг.
Теперь, вместо
<div *ngFor="#item of items">надо писать<div *ngFor="let item of items">.Такой код:
Раскрывается в такой:
https://github.com/angular/angular/issues/7158
А, ну я давно тыкал емакс, тогда package.el мало что умел.
В el-get намного больше готовых пакетов, он сам добавляет пути к пакету в load-path, так что достаточно только добавить
(require 'package-name). Ну и ещё много полезных и удобных штук, который отсутствуют в стандартномpackage.el.Ну это смотря для чего конфиг. Если настроить программу, у которой куча опций плагинов и др. возможностей — самое оно. Собственно, все современные редакторы кода построены по такому принципу. В мире nodejs тоже предпочтительнее использовать js-код, а не просто json. Банально уменьшает количество копипаста.
Мы же про ОС говорим? И про всякие более-менее стандартные (не узкоспециализированные) программы. Зачем с конфигом программы работать из другого софта? Кому может понадобится конфиг, например, nginx'а кроме него самого?
Если же некие конфиги будут использоваться кучей программ, то да, нужно что-то статическое и со схемами. Но тут xml наверное будет получше, хотя зависит от задачи.
Ещё есть Tcl. Из коробки есть почти в любом дистре. Плюс, приятное дополнение в виде Tk.
А вот у луа проблемы в плане работы с ОС (всякие операции с файлами и т.д.). Всё-таки он позиционируется больше как встраиваемый язык, так что там нет богатой стандартной библиотеки и удобной системы пакетов.
Ага, особенно радует отсутствие комментов, один вид кавычек, необходимость эти кавычки ставить в ключе, отсутствие trailing comma (это когда нельзя делать так:
[1, 2, 3,]), скудность типов, и ещё куча недостатков. Наличие попыток сделать свой формат на основе JSON или добавить ему костыли — лишнее тому подтверждение.Если настройки сводятся к ключ-значение, то ini и подобные ему куда лучше. Если настройки начинают выходить за эти рамки, то по мне уж лучше писать конфиг на каком-то языке программирования, например lua или js.
Нектопост какой-то. Если и брать первую версию, то 1.5, там много хороших нововведений. Ну а по-хорошему, второй версией спокойно можно пользоваться уже сейчас. Лучше напишите, как мигрировать с 1-й на вторую.
Понятно. Тогда да, всё логично.
JAVA_HOME
Фреймворк фреймворку рознь. Питоновский фласк изучить можно за день-два. Но без реального опыта разработки на нём, знания самого фреймворка мало что дадут.
Ситуации тоже бывают разные. Например, уволился человек, который писал какую-то часть проекта или проект на фреймворке X. Нужно срочно найти замену. Никто не станет рисковать, и брать человека без опыта, лучше сразу найти знающего специалиста. Если же есть команда, но требуются лишние руки, то часто принимают людей даже без знания языка, лишь бы был обучаем. А в конце испытательного срока всё встанет на свои места.
Чем же он печален? Тем, что рутину теперь делают за тебя? Ну что же, инструменты развиваются в любой области. Раньше операции на глазах были практически невозможны, зато сейчас в любой клинике лазером могут подкорректировать зрение. Это тоже грустно?
Вот есть заказ на проект, с заранее оговоренной суммой. Основное требование — надёжность, на скорость по большей части плевать.
Вася пишет на скучной джаве, у него память сама подчищается, ошибки отлавливаются, а времени он тратит на всё это немного, так что успевает спать по ночам. Проект он сдаст через месяц, а потом поедет отдыхать.
А вот Петя пишет на интересном C, у него насыщенная жизнь: нужно постоянно следить за ресурсами, освобождать память вручную, следить за указателями, чтобы за диапазон не вышли. Он вручную анализирует ошибки по их кодам, стектрейсы составляет сам и все ночи сидит в дебаггере. Через полгода он ещё возится, деньги уже кончаются (полгода ведь надо что-то есть и где-то жить).
gmail offline? Да и разговор был о том, что сокращается функционал браузера. Ведь функциональность браузера — это ещё и его апи, позволяющее писать что-то для него. Так что если сравнить, что можно было сделать в браузере с расширениями/приложениями раньше и сейчас — то разница будет разительная. Достаточно посмотреть на приложения в магазине хрома. Да, в старую оперу встроили кучу сопутствующих приложений. А сейчас они просто ставятся отдельно.
Сейчас, например, в моём браузере есть табличный и текстовый процессор, редактор презентаций (и они работают офлайн). Было ли что-то подобное в старых браузерах или среди дополнений для них?
И что, много ваших патчей отклонили?
Вот смотрю я на популярные проекты, их issues. Очень много issues, которые заводят, не баги продукта, а не умение людей правильно пользоваться этим продуктом. Соответственно, пулл-реквесты и патчи тоже порой шлют такие, что лучше бы не высылали.
Форк же (если он качественный), сможет сдвинуть с мёртвой точки продукт (см. nodejs и io.js).
Что касательно webkit, его разрабатывает огромное количество людей и компаний.
Вот пример, как можно внести свой вклад в разработку chromium. Ещё можно почитать, как разрабатывают хромиум.
Так что, как говорил Линус: “Talk is cheap. Show me the code.”
Удобно всё валить на систему, корпорации и бизнес. Вот только если у человека есть амбиции и навыки, он найдёт как выделиться, особенно в наше время. Самый банальный способ: завести проект на гитхабе.
«Эрланг учится за две недели, за год можно выучить до 26 эрлангов.»
Написано на нём довольно много. Всё работает обычно 24/7, его для этих целей и создавали.
Ну и так по каждому пункту. Если уж писать аналогии, то более честные.