Tuesday, October 23, 2012


Заметка полностью.

Метод решения квадратных уравнений с помощью дискриминанта знают почти все. Но, как мне пришлось убедиться, для многих эта формула: D = b2 - 4ac кажется своего рода заклинанием. И почему для получения корней сначала нужно произвести именно такую операцию с коэффициентами - загадка.

Ниже есть продолжение.

тобы понять, откуда взялась формула дискриминанта и почему она работает, попробуем решить квадратное уравнение без неё.

Итак, имеем уравнение ax2 + bx + c = 0, где первый коэффициент не равен нулю.

Для начала разделим обе части на a:


Было б здорово, если бы левую часть удалось свернуть по формуле квадрата суммы. Квадрат первого, x2 , уже есть. Тогда удвоенным произведением первого на второе должно стать:


Квадрат второго будет равняться


Прибавим его и отнимем от левой части уравнения:


Соберём три слагаемых левой части в квадрат суммы, а оставшиеся два - перенесём вправо:


Приведём правую часть к общему знаменателю:


Вот он! Выражение b2 - 4ac, стоящее в числителе правой части - и есть наш дискриминант. Почему же его знак определяет количество корней? Рассмотрим полученное уравнение внимательнее. Слева стоит квадрат. В знаменателе правой части - тоже квадрат. И только дискриминант может иметь любой знак. Поэтому, если он окажется отрицательным, полученное уравнение корней иметь не будет. Если нулевым - корень будет единственным (кстати, формула нахождения вершины параболы также происходит отсюда). И только для положительного дискриминанта будет 2 различных корня.

Ну а дальше - легко :)

Jim Coplien and Bob Martin Debate TDD (English)

Bob Martin is also known as Uncle Bob. He is an Agile Manifesto author, and author of books on Agile Programming, XP, UML, Object Oriented Programming, and C++.

Jim Coplien is a software pioneer in Object Oriented programming and C++ and multi-paradigm design. He is also co-author of DCI paradigm.

Debate sprang up at JAOO '07 around Bob Martin's assertion that "nowadays it is irresponsible for a developer to ship a line of code he has not executed in a unit test." In this InfoQ video, he debated with Jim Coplien on this and other topics, including Design by Contract vs. TDD and how much up-front architecture is needed to keep a system consistent with the business domain model.

There is full transcription below.
Ниже есть продолжение.

Introduction by Floyd Marinescu
I am here with Jim Coplien and Bob Martin at the JAOO Conference and here we have 2 very interesting divergent opinions on what is the value of TDD. So let's open up the floor and let each one have a couple of minutes of say. Let's hear you guys talk about it!

Bob Martin: First thing I need to say is: I am sitting here next to one of my heroes. I read Jim's book in 1991-1992, changed the way I thought about software, changed the way I thought about C++ in particular, so it's a great honor for me to be here. I think we have a disagreement - I'm not sure, possibly, it may a difference in perspective - but my thesis is that it has become infeasible, in light of what's happened over the last 6 years, for a software developer to consider himself "professional" if he does not practice test driven development.

Jim Coplien: Well it may be good, because you did this at your keynote yesterday: you said what you mean by "test driven development". I have adopted a very strong position against what particularly the XP community is calling test driven development. And I have audited this versus a lot of tutorials at about 4 conferences in the past 6 months and they give a very consistent story on what they mean. Here, it was a little bit different yesterday, so maybe for the sake of making this a meaningful conversation you can quickly reiterate so we are on the same page.

Bob Introduces his 3 laws of TDD and Jim Responds

B: So I have 3 laws of test driven development. The first one is: a test driven developer does not write a line of production code until he has written a failing unit test, and no production code can be written until there is a failing unit test.

the second law is, you do not write more of a unit test than is sufficient to fail, and not compiling is failing. So you cannot write very much of the unit test before you write production code.

The third law is you cannot write more production code than is sufficient to pass the test. You cannot write a little bit of unit test and then run off and write production code. These three laws lock you into a cycle that is perhaps 30 seconds long, and that means that you are actually writing unit tests and production code concurrently, with the tests perhaps 30 seconds to a minute ahead. That is my definition.

J: Per se, the main concerns I have about TDD are not problematic with respect to what you've just said in isolation, so if it's no more and no less than that we may not have a big disagreement. What my concern is, then, comes out of doing broad work with a lot of clients and a little bit of interactions with other consultants and other scrum masters who have seen these things happening in their project. And we've seen 2 major problems: one is that use of TDD without some kind of architecture or framework into which you're working - which was very strongly Kent's original position: you use TDD to drive your architecture - leads to a procedural bottom-up architecture because the things you are testing are units.

We just had a discussion upstairs about "is TDD the same as unit testing?" Well, no, it's a little more, but unit testing was a great idea in Fortran, when you could build these layers of APIs and the units of organization of the software were the same as the units of testing, but today the units of organization of the software are objects and we're testing procedures and there is a little bit of a mismatch. Now, if you are using the procedures to drive your architecture, I think you are trying to build a 3 dimensional structure from 2 dimensional data, and you end up going awry. And one of the things we see a lot, in a lot of projects, is that projects go south on about their 3rd sprint and they crash and burn because they cannot go any further, because they have cornered themselves architecturally. And you can't refactor your way out of this because the refactoring has to be across class categories, across class hierarchies, and you no longer can have any assurances about having the same functionality.

The other problem we've seen is that this destroys the GUI and this is what Trygve [Reenskaug, another co-author of DCI] and I talk a lot about, because you have this procedural architecture kind-of in a JAVA class wrapper; you no longer are driving the structure according to domain knowledge and things that are in the user's conceptual model of the world, which is where object orientation came from. I mean even Kent, as he's very often said: "you can't hide a bad architecture with a good GUI." The architecture will always shine through to the interface, and I strongly believe that, and that is why I believe we need something in the infrastructure that gives you a picture of what the domain model is out at the interface. Then, if I want to apply Uncle Bob's 3 rules I probably don't have a problem with that, but I want a starting place that captures this other dimension, which is the structural dimension.

B: Alright. But you do not accept the thesis that the practice of test driven development is a pure requisite to professional behavior in 2007.

J: I absolutely do not accept that.

B: OK. So we can come back to that one because I think that is an interesting topic, just on the topic of professionalism, but before we do that: there has been a feeling in the Agile community since about '99 that architecture is irrelevant, we don't need to do architecture, all we need to do is write a lots of tests and do lots of stories and do quick iterations and the code will assemble itself magically, and this has always been horse shit. I even think most of the original Agile proponents would agree that was a silliness. I think if you went and talked to Kent now he would be talking about what he always talked about: metaphor, whatever the heck that was.

J: And in fact he says this, in "XP explained" or something, his page 131 of his book he says: "Yes, do some up-front architecture, but don't knock yourselves out".

B: Sure. OK. But now let me come back and throw a different light on this. I think architecture is very important, I've written lots of articles and books about architecture, I am the big architecture freak. On the other hand I don't believe architecture is formed out of whole cloth. I believe that you assemble it one bit at a time, by using good design skills, by using good architectural skills, over the weeks and months of many iterations. And I think that some of the architectural elements that you create, you will destroy; you will experiment in a few iterations with different forms of architecture. Within 2 or 3 iterations you will have settled into the architecture you think is right and then be entering into a phase of tuning. So my view of that is that the architecture evolves, it is informed by code that executes, and it is informed by the tests that you write.

J: I do agree that architecture evolves, I do believe it's informed both by the code that you write and, maybe even earlier, by use cases that come in, that inform you about things that are relating to scope and other relationships; but if you try to do things incrementally, and do them literally incrementally, driven by your interaction with the customer without domain knowledge up-front, you run the risk that you do it completely wrong.

I remember when I was talking with Kent once, about in the early days when he was proposing TDD, and this was in the sense of YAGNI and doing the simplest thing that could possibly work, and he says: "Ok. Let's make a bank account, a savings account." What's a savings account? It's a number and you can add to the number and you can subtract from the number. So what a saving account is, is a calculator. Let's make a calculator, and we can show that you can add to the balance and subtract from the balance. That's the simplest thing that could possibly work, everything else is an evolution of that.

If you do a real banking system, a savings account is not even an object and you are not going to refactor your way to the right architecture from that one. What a savings account is, is a process that does an iteration over an audit trail of database transactions, of deposits and interest gatherings and other shifts of the money. It's not like the savings account is some money sitting on the shelf on a bank somewhere, even though that is the user perspective, and you've just got to know that there are these relatively intricate structures in the foundations of a banking system to support the tax people and the actuaries and all these other folks, that you can't get to in an incremental way. Well, you can, because of course the banking industry has come to this after 40 years. You want to give yourself 40 years? It's not agile.

So you want to capitalize on what you know up-front, and take some hard decisions up front, because that will make the rest of the decisions easier later. Yes, things change; yes, architecture evolves; and I don't think you'd find anyone who will say "put the architecture in concrete". I also do not believe in putting the code in place, that is, the actual member functions, up front. You put the skin, you put the roles, you put the interfaces that document the structure of the domain knowledge. You only fill them out when you get a client who is willing to pay for that code, because otherwise you are violating Lean. So you do things "just in time," but you want to get the structure upfront, otherwise you risk driving yourself into a corner.

B: So I would say that a little differently, and take exception to some of it. I would not very likely fill in the interfaces with abstract member functions or defunct member functions. I might create objects that will fill the place of interfaces. So, in Java terms, I might have an "interface-something" with nothing in it, but I am not going to load it with a lot of methods that I think might be implemented one day. That is something that I am going to let my tests drive, the requirements drive, and I am going to be watching it like a hawk to see if there is any kind of architectural friction that would cause me to split that interface.

J: But the problem is: that's like saying that words have meaning apart from any definition. And so the fact that I call something a mule, without saying what a mule is, doesn't make it a mule. Like Abraham Lincoln said, "Calling a mule an ass doesn't make it one." And so the thing that gives meaning to stuff is the member functions as semantics. You don't want to go crazy and you don't want to be guessing, and here is where I agree with Kent. He says in the "XP Explained" book: "You don't want to be guessing" and that is true. But I do want to assert what I know and there are some things you just know about the structure of a telecom system, a banking system. You know that you don't build a recovery object. I was on a restructuring project in a large telecom company once where they were redoing a toll switch using object oriented techniques and modern computer science techniques, and I got assigned to work with the guy who was making the recovery object. Well this is ludicrous, recovery isn't an object, but yet his superficial knowledge of the domain let him do that. If you get down to understanding what the member functions of that are then you will see this isn't even an object. So you ask: "How do I know it's not an object? What are its member functions?" "Uh... to recover". "Great. That is a lot of help." Actually I think there are people who have capitalized on this and it's now called SOA. That is the danger.

You want to have something there to give the object meaning.

B: OK. And I would even agree with that. You need something there to give the object meaning. I am going to be really minimal about that.

J: Me too. No disagreement.

B: And then I am going to let executing code inform my future decisions, so I am not going to create a massive architecture, or a huge system based on speculation.

J: That is right. No disagreement.

B: So back to the beginning: how long would you spend before you started writing executable code. Let's say, on a system that will eventually wind up being two million lines of code?

J: So, 2 million is, in my experience, pretty small. I am working with hundreds of millions. Before the first executing code... it depends a lot on the individual system, but let's say I were building a simple telecom system. What I would probably do, let's say I am doing it in C++, I would have at least constructors and destructors in place and be able to start to wire up important relationships between the objects and...

B: Would you have tests, testing those wirings?

J: I would have tests for those wirings. An obvious test is to make sure, when the system comes up and goes down, that the memory is clean, for example. Half an hour.

B: Excellent. So where is our disagreement? Perhaps our disagreement is on the notion of TDD and professionalism. That was the second part.

J: I think that is a separate disagreement, but maybe we can put this one to rest, this is nice. But the thing I want to make clear for the audience is that, again, I think when I am running into people that are doing things right, that avoid the kind of problems they talked about earlier, it's not TDD out-of-the-book or TDD out-of-the-box. So, people have found a way to move to what Dan North now calls BDD, for example, which I think is really cool (if you ignore the RSpec part and all the stuff which is kind of dragging it back to too low of a level).

So there are a lot of people doing the right thing and my concern is that they are calling this good thing TDD and then people are going to buy books and they are going to look up TDD and they are going to find this old thing which is "architecture only comes from tests," which I have heard four times in tutorials in the past 6 months, and that is just, like you say, horse shit. But now, on to the professionalism issue, how would you know a professional if you saw one?

B: They practice TDD? (smiling)

J: "Professional," to me, is just someone who makes money for doing a job in that area.

B: Yeah, I know, and I am going to push on that one, because I think that something our industry has lacked is a standard of professionalism.

J: We'll take your definition as a starting point and then we can talk about that.

B: But that is not actually my definition, I was joking. I think that nowadays it is irresponsible for a developer to ship a line of code that he has not executed in a unit test, and one of the best ways to make sure that you have not shipped a line of code that you have not tested is to practice TDD.

J: I do disagree with that. Now, I think there is something deeper that is important, and let me attack this by example. As an example of something I could do as an alternative: I could wave my hands and say a lot of things about code inspections or pair programming and those are good and probably have more value, but it's kind of an independent discussion. But let me give you something that I think hits the nail on the head even more importantly. Let's look what a unit test is. What a unit test does is: looks at an API of a procedure and kind of goes and hits the state space of the arguments and maybe hits a half a dozen of them, or a hundred or a few million of (2 to the 32nd power) or whatever, and so you're just doing hit and miss. That is really heuristic, you've got to be really lucky to find bugs doing that.

What I think is more powerful is "design by contract." So you have preconditions, post conditions and invariants. Now, the technology isn't there in most languages. They haven't matured to the point where Eiffel has, where you can statically check these things, but you can build additional infrastructure to do that kind of thing. I think it has all the advantages TDD, there are these advantages (supposed advantages), about: I am going to think hard about the code, I am going to focus on the external view and so forth. And I have found, at least for me, that contracts do that more effectively than tests do. Furthermore, they actually give you broader coverage because you are covering the entire range of the arguments rather than just randomly scattering some values in there.

Now, Bertrand Meyer actually taken this further and he has something called CDD, which is Contract Driven Development, where what he does is: he takes contracts and he kind of feeds random numbers at them and if they don't meet the preconditions you don't run them because you know that test will fail, but he tests if the post conditions hold after you run the test, and if they don't it's a bug. And they have actually done this. They have a tool that automatically runs tests. They have done this on the Eiffel library and they ran it about a week, they found 7 bugs in the 20 year old Eiffel library - that is kind of interesting. But it comes from a part of the code where you are expressing intentionality in a way that has hope of being traced back to something of business importance, and the problem about TDD, as most people practice it down at the class level, is that it's really, really difficult to trace those APIs at a class level sometimes all the way up to business significance.

B: So I am having trouble with that. As I remember Eiffel - and I actually thought this discussion was put to bed a long time ago - as I remember Eiffel and "design by contract," you specify preconditions, post conditions and invariants around every method and around your class, the invariants of your class. Test driven development, or a suite of unit tests, virtually does the same thing, it specifies a set of incoming checks on the arguments, outgoing checks on the returned values, explores the state space, as you said, of the methods. So I always thought that they were one-to-one, you could always transform contracts into unit test or transform unit tests into contracts, with the exception that the direction of the dependencies is different, and you know that I am a big dependency freak. Unit tests depend on code, on production code, which I think is good, production code doesn't depend on unit tests; whereas contracts are smeared through the code, which bothers me.

B: I think you are creating a dualism that needn't be created, in that there is one thing, which is the code, the code is the design, it's what's delivered, anything else is not Lean. In typical projects that use unit testing, the code mass is about the same as a test mass, and where there is code, there's bugs. You cut your velocity in half. There is well known examples, the most famous example is the ADA compiler where actually, use of test driven development increased the number of bugs in the code, because your code mass increases, because you have more tests. If you are using assertions you have this nice coupling, that is essential coupling, between the semantics of the interface and the code itself. Whereas with the tests the coupling is a lot messier and hard to manage. There was another point you've made I was going to react to...

J: I am surprised that you think the code mass is different.

J: In my experience, it is. If I look at how people actually use this: I like it when I see a JUnit spec that looks like assertions, but a lot of the time it isn't.

B: I agree with that: there are messy tests, but there is messy code. I don't like arguments that the "tool is easy to abuse therefore you shouldn't use it," that would invalidate almost everything...

J: That isn't my argument. My argument is: how I am seeing this being used in broad practice - and they are not getting it.

B: Well, OK. And do you see contracts being abused in broad practice?

J: First of all, they are not being used enough...

B: Right! By the way, since we've just got a couple of minutes left, just a trivia question - and I don't know the answer. Who is it that first used "DD" with some letter in front of it? We've got CDD now, we've got BDD, TDD and I don't know what else and the earliest one I can remember is Rebecca Wirfs-Brock, Responsibility Driven Design. Was there an earlier one?

J: DD ... was a UNIX command to do disk dump... but that probably doesn't count. Thank you Bob, good seeing you again.

Выдеркжи из книги Элиот Рузвельт. "Его глазами."

...Элиот Рузвельт, сын президента США Франклина Рузвельта, исполнял роль адъютанта отца на некоторых международных конференциях второй мировой войны...возле Франклина Рузвельта всегда находился близкий человек, которому президент доверял, и с которым он мог бы спокойно обсудить ход переговоров.

Ниже есть продолжение.

...для начала о причинах войны.
Вот заявление президента США, сделанное им на одной из встреч.
«— Мир, — твердо сказал отец, — не совместим с сохранением деспотизма. Дело мира требует равенства народов, и оно будет осуществлено. Равенство народов подразумевает самую широкую свободу торговой конкуренции. Станет ли кто-нибудь [53] отрицать, что одной из главных причин возникновения войны было стремление Германии захватить господствующее положение в торговле Центральной Европы?»

«— Есть еще одно обстоятельство, — сказал отец. — На карту поставлена судьба Британской империи. Английские и германские банкиры уже давно прибрали к рукам почти всю мировую торговлю — правда, не все отдают себе в этом отчет. Даже поражение Германии в прошлой войне не изменило дела. Так вот, это не слишком выгодно для американской торговли, не правда ли? — Он приподнял брови и [41] взглянул на меня. — Если в прошлом немцы и англичане стремились не допускать нас к участию в мировой торговле, не давали развиваться нашему торговому судоходству, вытесняли нас с тех или других рынков, то теперь, когда Англия и Германия воюют друг с другом, что мы должны делать? Одно обстоятельство для нас уже совершенно ясно. Мы не можем позволить себе действовать корыстно и выбирать, на чью сторону нам стать, руководствуясь только соображениями наибольшей выгоды. Оставим на минуту в стороне, что нацизм нам ненавистен и что наши естественные интересы, наши сердца на стороне англичан. Есть и другой подход к вопросу. Мы должны с самого начала ясно сказать англичанам, что мы не намерены быть просто добрым дядюшкой, которого Британская империя может использовать, чтобы выбраться из трудного положения, и потом навсегда забыть.
— Я не совсем понимаю, к чему ты клонишь, — вставил я.
— Черчилль заявил мне, что он стал премьер-министром Его Величества не для того, чтобы председательствовать при ликвидации Британской империи (впоследствии Черчилль повторил это заявление по радио). Мне кажется, я выступаю как президент Америки, когда говорю, что Америка не будет помогать Англии в этой войне только для того, чтобы дать ей возможность попрежнему беспощадно подавлять колониальные народы. — Отец помолчал.»
Реакция Черчилля на это показательна.

«После обеда Черчилль все еще руководил разговором. Однако перемена уже начинала сказываться. Впервые она резко проявилась в связи с вопросом о Британской империи. Инициатива исходила от отца.
— Конечно, — заметил он уверенным и несколько лукавым тоном, — конечно, после войны одной из предпосылок длительного мира должна быть самая широкая свобода торговли.
Он помолчал. Опустив голову, премьер-министр исподлобья пристально смотрел на отца.
— Никаких искусственных барьеров, — продолжал отец. — Как можно меньше экономических соглашений, предоставляющих одним государствам преимущества перед другими. Возможности для расширения торговли. Открытие рынков для здоровой конкуренции. — Он с невинным видом обвел глазами комнату.
Черчилль заворочался в кресле.
— Торговые соглашения Британской империи... — начал он внушительно. Отец прервал его:
— Да. Эти имперские торговые соглашения, — о них-то и идет речь. Именно из-за них народы Индии и Африки, всего колониального Ближнего и Дальнего Востока так отстали в своем развитии.
Шея Черчилля побагровела, и он подался вперед.
— Господин президент, Англия ни на минуту не намерена отказаться от своего преимущественного положения в Британских доминионах. Торговля, которая принесла Англии величие, будет продолжаться на условиях, устанавливаемых английскими министрами.
— Понимаете, Уинстон, — медленно сказал отец, — вот где-то по этой линии у нас с вами могут возникнуть некоторые разногласия. Я твердо убежден в том, что мы не можем добиться прочного мира, если он не повлечет за собой развития отсталых стран, отсталых народов. Но как достигнуть этого? Ясно, [52] что этого нельзя достигнуть методами восемнадцатого века. Так вот...
— Кто говорит о методах восемнадцатого века?
— Всякий ваш министр, рекомендующий политику, при которой из колониальной страны изымается огромное количество сырья без всякой компенсации для народа данной страны. Методы двадцатого века означают развитие промышленности в колониях и рост благосостояния народа путем повышения его жизненного уровня, путем его просвещения, путем его оздоровления, путем обеспечения ему компенсации за его сырьевые ресурсы.
Все мы наклонились вперед, стараясь не проронить ни слова из этой беседы. Гопкинс улыбался, адъютант Черчилля, коммодор Томпсон помрачнел и был явно встревожен. У самого премьер-министра был такой вид, как будто его сейчас хватит удар.
— Вы упомянули Индию, — прорычал он.
— Да. Я считаю, что мы не можем вести войну против фашистского рабства, не стремясь в то же время освободить народы всего мира от отсталой колониальной политики.
— А как насчет Филиппин?
— Я рад, что вы упомянули о них. Как вам известно, в 1946 г. они получат независимость. А кроме того, они уже располагают современными санитарными условиями, современной системой народного образования; неграмотность там неуклонно снижается...
— Какое бы то ни было вмешательство в имперские экономические соглашения недопустимо.
— Они искусственны...
— Они составляют основу нашего величия.»


В завершение переговоров между Президентом США Франклином Делано Рузвельтом и Премьер-министром Великобритании Уинстоном Черчиллем, состоявшихся на борту военных кораблей в Атлантическом океане, близ острова Ньюфаундленд, 14 августа 1941 г. была подписана декларация, получившая название «Атлантическая хартия».
24 сентября 1941 г. СССР заявил о присоединении к этой декларации, подчеркнув при этом, что применение принципов Хартии «должно будет сообразоваться с обстоятельствами, нуждами и историческими особенностями той или другой страны». В том заявлении также отмечалась важность того, чтобы «сконцентрировать все экономические и военные ресурсы свободолюбивых народов для полного и возможно более скорого освобождения народов, стонущих под гнетом гитлеровских орд». 1 января 1942 г. представители правительств, поддержавших Хартию, подписали в Вашингтоне Декларацию 26 государств.

Текст атлантической хартии:

Президент Соединенных Штатов Америки и премьер-министр господин Черчилль, представляющий Правительство Его Величества в Великобритании, встретившись друг с другом, считают разумным обнародовать определенные общие принципы государственной политики соответствуюших стран, на основе которых базируются их надежды на лучшее будущее и я всего мира.
Первое: их страны не стремятся к территориальным или иным приобретениям.
Второе: они выражают желание не быть свидетелями территориальных изменений, которые не соответствуют свободно выраженным пожеланиям интересованных народов.
Третье: они уважают право всех народов избирать форму правления, при которой они будут жить, и они желают видеть суверенные права и самоуправление восстановленными для тех, кто был насильственно лишен их.
Четвертое: они будут стремиться с должным уважением к своим обязательствам к тому, чтобы способствовать обеспечению всем государствам, большим или малым, победителям или побежденным, равного доступа к торговле и сырьевым запасам мира, необходимым для их экономического процветания.
Пятое: они выражают желание способствовать в полной мере сотрудничеству между всеми государствами в экономической области с целью всеобщего обеспечения более совершенных условий труда, экономического прогресса и социальной безопасности.
Шестое: после окончательной ликвидации нацистской тирании они надеются увидеть установление мира, который предоставит всем государствам возможность жить в безопасности в их собственных границах и который позволит гарантировать, что все люди на земле смогут жить в условиях свободы от страха и лишений.
Седьмое: такой мир должен будет позволить всем людям беспрепятственно пересекать открытое море и океаны.
Восьмое: они выражают веру в то, что все государства мира, как исходя из чувства реальности, так и по причинам возвышенного характера, придут к решению отказаться от использования силы.
Поскольку будущий мир не может быть сохранен, если государства, которые угрожают или могут угрожать агрессией за пределами своих границ, будут продолжать применять оружие наземного, морского или воздушного назначения, они выражают веру в то, что разоружение таких государств необходимо при условии создания более широкой и постоянной системы общей безопасности. Аналогичным способом они будут содействовать и поощрять все иные практически осуществимые меры, которые облегчат для всех миролюбивых народов тяжелое бремя вооружений.

Франклин Д. Рузвельт
Уинстон С. Черч

...О Де Голле...

«— Де Голль зазнался, — сказал премьер-министр, — и отказывается приехать сюда. Категорически! — [83] Казалось, что Черчиллю почему-то доставляет удовольствие рассказывать о своих затруднениях.
— Не могу заставить его выехать из Лондона, — продолжал премьер-министр бодрым тоном. — Он в бешенстве от тех методов, которые мы применили, чтобы взять под свой контроль Марокко, Алжир и Французскую Западную Африку. Он воображает себя Жанной д'Арк. А теперь, когда «Айк»{3} отдал здесь власть Жиро, конечно... — Черчилль горестно покачал головой.»

И далее:

«Отец рассмеялся.
— Не знаю, но надеюсь выяснить это в ближайшие дни. Однако я сильно подозреваю, — на этих словах он сделал особое ударение, — что наш друг де Голль не прибыл до сих пор в Африку только потому, что наш друг Уинстон пока еще не счел нужным пригласить его сюда. Я более чем уверен, что в данный момент де Голль сделает решительно все, о чем его попросят премьер-министр и английское министерство иностранных дел.
— Почему?
— Совпадение интересов. Англичане намерены не выпускать свои колонии из рук и хотят помочь французам удержать их колонии. Уинни — великий поборник «статус-кво». Ведь он и сам похож на «статус-кво», не правда ли?»

Вопрос: может ли Англия заботиться о том, что бы у Франции сохранились колонии?
Ответ: ДА, если это выгодно Англии. И Де Голль, являющийся сторонником сильной Франции будет союзником Черчилля в этом вопросе.
Я не стану описывать те интриги, которые происходили в руководстве французского сопротивления и около него. Желающие могут прочитать книгу сами.



Затем он заговорил о том, что, по его мнению, нужно сделать: Францию нужно восстановить как мировую державу и отдать ей под опеку ее бывшие колонии. Как опекун она должна будет ежегодно отчитываться в своем руководстве, в том, как повышается уровень грамотности, как падает смертность, как идет борьба с болезнями, как...
— Погоди, — прервал я его. — Перед кем же она будет отчитываться?
— Перед организацией Объединенных наций, когда она будет создана, — ответил отец. Тогда-то я впервые услышал об этом плане.
— А как же иначе? — сказал отец. — «Большая четверка» — мы, Англия, Китай, Советский Союз — будет нести ответственность за мир во всем мире, когда...
— «Если»... — поправил я. — Если... Я сказал это отчасти в шутку, отчасти всерьез, из суеверия.
— Нет, «когда», — твердо сказал отец. — Когда мы выиграем войну, четыре великие державы будут нести ответственность за мир. Пора нам уже подумать о будущем и начать готовиться к нему. Возьми, например, Францию. Франция должна будет занять подобающее ей место в этой организации. Великие державы должны будут взять на себя обязанность нести просвещение всем отсталым, угнетенным колониям в мире, поднять их жизненный уровень, улучшить санитарные условия их существования. И когда они достигнут зрелости, мы должны предоставить им возможность стать независимыми, после того как Объединенные нации в целом решат, что они к этому готовы. Если мы этого не сделаем, мы можем с полным основанием считать, что нам предстоит еще одна война.»

Разговор с Султаном и Де Голлем.

«Султан выразил горячее желание получить самую широкую помощь для введения в своей стране современного просвещения и здравоохранения.
Отец указал, что для этого султан не должен позволять иностранным концессиям выкачивать ресурсы страны.
Тут Черчилль попытался перевести разговор на другую тему. Султан, однако, вернулся к прежней теме и спросил у отца, какие последствия будет иметь его совет в отношении политики будущего французского правительства.
Отец, играя вилкой, весело сказал, что, конечно, положение после войны будет резко отличаться от довоенного, в особенности в отношении колоний.
Черчилль закашлялся и снова заговорил на совершенно другую тему.
Султан вежливо осведомился, что именно имел отец в виду, говоря о «резком отличии».
Отец вскользь упомянул о связях, существовавших в прошлом между французскими и английскими финансистами, объединявшимися в синдикаты для выкачивания колониальных богатств. Затем он перешел к вопросу о возможности существования во Французском Марокко месторождений нефти.
Султан горячо ухватился за эту идею; он заявил, что всемерно поддерживает развитие всяких потенциальных ресурсов с тем, чтобы доходы от них шли в его пользу. Затем он выразил сожаление по поводу отсутствия среди его соотечественников ученых и инженеров, которые могли бы освоить эти ресурсы без посторонней помощи. [121]
Черчилль заерзал в своем кресле.
Отец деликатно указал, что обучение и подготовку инженеров и специалистов из марокканцев можно было бы, конечно, организовать, например, в лучших университетах Соединенных Штатов в порядке своеобразного культурного обмена.
Султан кивнул головой. Видно было, что если бы не требования этикета, он тут же стал бы записывать названия и адреса этих университетов.
Отец продолжал развивать свою мысль, вертя в руках стакан. Он сказал, что султану, вероятно, было бы нетрудно договориться с фирмами — американскими фирмами — об осуществлении такого плана освоения естественных ресурсов, какой он имел в виду. Этот договор мог быть заключен на основе определенного вознаграждения или процентных отчислений. Преимущество такой системы, утверждал ен, состояло в том, что она позволила бы суверенному правительству Французского Марокко в значительной мере сохранить контроль над своими ресурсами, получать большую часть доходов и, в конечном счете, целиком взять эти ресурсы в свои руки.
Черчилль закряхтел и перестал слушать.
Это был очень приятный обед, и все мы, за исключением одного человека, получили от него большое удовольствие.»
«Отец: — Я уверен, что мы сумеем помочь вашей великой стране вернуть свое место в мире.
Де Голль (Нечленораздельное мычание).
Отец: — И я заверяю вас в том, что моя страна сочтет для себя честью принять участие в этом деле.
Де Голль (мычание): — Это очень любезно с вашей стороны.»
Готов поспорить на некрупную сумму денег, что Де Голль в тот момент думал о том, что американцы возьмут с Франции за подобную помощь.
Вот Черчилль вёл себя так, как будто на его глазах известный ловелас соблазнял одну из его малолетних дочерей, а он, Черчилль, хочет его придушить, но это не возможно.))))
А вот султан либо дурак, либо им прикидывался. Какие перспективы появились у Марокко и как они были использованы мы можем наблюдать сейчас.

В завершении Рузвельт сказал сыну:
«— Мне хотелось бы знать... — он замолчал и потом начал снова. — Видишь ли, всегда в истории, на протяжении веков англичане действовали по одному и тому же образцу. Они умно и удачно выбирали союзников. Им неизменно удавалось выходить победителями из всех войн, в которых они участвовали, и сохранять реакционную власть над народами мира и над мировыми рынками.
— Да...
— На этот раз союзники Англии — мы. И это вполне правильно. Однако... и в Арджентии, и в Вашингтоне, и теперь здесь, в Касабланке... я пытался заставить Уинстона и всех остальных понять, что, хотя мы и являемся их союзниками и будем поддерживать их до самой победы, они отнюдь не должны считать, что мы делаем это только ради того, чтобы они могли попрежнему жить своими архаическими средневековыми имперскими идеями.»

10 "орлов" подряд

Джеймс Грайм, ведущий ютуб-канала о занимательной математике singingbanana, бросая монетку, 10 раз подряд получил выпадение "орла". Вот видеодоказательство:

Легко подсчитать, что вероятность подобного события чуть меньше одной десятой процента. Как же ему удалось заставить подобное произойти?

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


О числе Пи

Найдено на просторах интернета.

Мне как-то приспичило в одном приборе плотность энергии круглого пятна считать, зная диаметр. А математика там только целочисленная, так что нужна была дробь, хорошо приближающая "пи". Так один знаток гиматрий и Торы(!) мне сходу выдал
355/113 = 3.1415929.
Ивритское слово "шана" ("год") имеет числовое значение 355 (это и в самом деле год, по лунному календарю, принятому у евреев). Слово "пелег" ("половина") имеет числовое значение 113. Представь себе круг - год - и делящую его пополам линию (диаметр). Отношение одного к другому - "пи"! А прибор хорошо продавался :-)

Ниже есть продолжение.

...Египтяне могли запросто оценить расстояние от земли до солнца и pазмеp солнца. Для этого достаточно было измерить разницу во времени по солнечным часам. Опыт выглядит пpимеpно так. Hужно вывеpенные песочные часы, большие, напpимеp, 4-6 обоpотов за стуки. Эти часы синpонизиpуются (путем запуска) по солнечным часам в пункте А, затем часы пеpевозятся в пункт B (~1000 км на запад или восток). Там измеpяют насколько часы отстают или опеpежают солнечные. Таким обpазом, можно опpелить ход Солнца за час. Затем можно замеpить угол склонения (от полуденного положения) Солнца за час. Этого достаточно чтобы оценить pасстояние до Солнца, а зная его угловой pазмеp опpеделить и его линейный pазмеp. В качестве единицы измеpения удобно было пpинять pасстояние от А до B. Чтобы пpоделать все эти pасчеты и измеpения у египтян были все возможности. Конечно, точность была бы не высокая, но не ниже 20-30%. Получилось бы что-нибудь типа "до Солнца в 100000 pаз дальше, чем от Мемфиса до Тиpа". Дpугой вопpос, пpоделали египтяне это исследование или нет.

Что значит (ЮМОР)

Из архивов.

Если генерал говорит: "Да!" - значит "да".
Если генерал говорит: "Нет!" - значит "нет".
Если генерал говорит: "Может быть" - значит, он не генерал.
Если дипломат говорит: "Да!" - значит "может быть".
Если дипломат говорит: "Может быть" - значит "нет".
Если дипломат говорит: "Нет!" - значит, он не дипломат.
Если женщина говорит: "Нет!" - значит "может быть",
Если женщина говорит: "Может быть" - значит "да".
Если женщина говорит: "Да!" - значит она не женщина.

Продолжается массивный обстрел Западного Негева

צבע אדום - אשכול - 19:16 (יציאה מספר 6 ככל הנראה)

When China Rules The World Revisited (English)

По наводке блога Давыдова.

Надо ли учить считать?

Короткий отрывок.

Кстати, недавно была интересная дискуссия о том, надо ли учить детей считать. Я убеждён, что надо, но не ради решения бытовых проблем..., а ради будущего обучения. Пока ребёнок учится работать с маленькими числами, его мозг адаптируется для освоения будущих более сложных конструкций. Научить ребёнка пользоваться калькулятором не очень трудно, но как его потом учить алгебре, если он не «трогал» простейших объектов? Для него естественная и красивая алгебра превратится в пустой набор правил для преобразования строк. А в таком режиме он не сможет развить минимальную интуицию, которая помогала бы ему выбирать нужные правила, чтобы справляться с простейшими задачами...Как без минимальной алгебры решать задачки по физике, например?..

Как появление калькулятора стало аргументом против таблицы умножения, так и развитие интернета стало аргументом против чтения. Нас спрашивают, а зачем читать, если всегда можно будет загуглить? И дело тут даже не в сомнительности слова «всегда», а в том, что голова, недостаточно развитая в детстве для поглощения больших объёмов информации, не сможет в будущем породить что-то новое. Как можно создать новую теорию, не освоив хотя бы частично существующие? И здесь никакой гуглёж не поможет, так как надо не дату рождения поэта уточнить, а лучше авторов понять большие и сложные теории, чтобы исправить их или предложить новую, которая решает известные проблемы старых.