Интересно, как мысли/информация кругами ходит
Цитата
Разрешимость и даже complexity являются математическими игрушками и часто играют злые шутки с инженерами.
...
Представьте что надо написать программу, создающую будку на Х собак, где Х - натуральное. Но задача не решаема в общем виде! На 1-2 собаки надо делать классическую будку типа Плуто, на 3-10 - вольеры из сетки в ряд, а на большее число - уже целые комплексы в инете я видел, т.к. надо решать совершенно другие проблемы вроде массового выгула.
Но точно такая же ситуация например с задачей коммивояжёра. При некоторых размерах она тривиальным циклом решается, при некоторых требует распараллеливания, при некоторых требует суперкомпьютера с хорошим интерконнектом, а при некоторых вообще не имеет физического смысла т.к. ждать годы. Соответственно бред же доказывать что-то для стейт оф зе арт программы для суперкомпьютера за пределами суперкомпьютерных размеров задач.
...
Короче, основная масса работы - это неуниверсальный код, для которого доказывать что он валиден на всей бесконечности натуральных - это какой-то адов оверинжиниринг. Практики не поймут!
Конец цитаты
http://nponeccop.livejournal.com/507802.html
И это замечательно перекликается с выступлением
Alan Kay at OOPSLA 1997 - The computer revolution hasnt happened yet
https://youtu.be/oKg1hTOQXoY
Где у него, внимание, есть пример про собачью будку! Причем примерно в том же контексте.
Обожаю послушать умных людей.
original post http://vasnake.blogspot.com/2016/09/dog-house.html
Tools
Записки программиста, обо всем и ни о чем. Но, наверное, больше профессионального.
2016-09-11
Dog house
Posted by
Valentin
at
19:39
0
comments
Labels: CS, programming, Wisdom
2016-09-10
Design patterns
Об https://en.wikipedia.org/wiki/Software_design_pattern
Краткое содержание:
паттерны -- это типа словарь, чтобы люди могли говорить на одном языке, обсуждая код.
Культивировать надо понимание (и умение рассуждать об) применимости тех или иных паттернов.
Цитата
Here's the deal with design patterns ... They are observations, not rules. People noticed that programmers seemed to be approaching problems in similar ways in a bunch of different applications, and they decided that it would be pretty useful to be able to talk about those approaches using a common vocabulary so they wouldn't have to keep explaining what they were referring to. So they figured out general versions of these common practices and gave them names like "Visitor" and "Observer."
But the important part is "understand why." The skill you need to cultivate to become a good developer and to be attractive to the kinds of companies in the question isn't plugging together objects from a library of canned formulas, but rather understanding the reasoning behind them deeply enough that, when faced with the same problem, you will arrive at the same solution on your own. And much more importantly, when faced with a similar but not identical problem, you will do something else rather than try to shoehorn the solution into an existing design pattern that's an awkward fit.
Конец цитаты
https://www.quora.com/What-are-the-most-important-design-patterns-that-software-engineers-should-know-to-work-at-Google-Amazon-and-Facebook/answer/Steven-Grimm
original post http://vasnake.blogspot.com/2016/09/design-patterns.html
Posted by
Valentin
at
22:25
0
comments
Labels: programming
2016-09-01
UPS
Posted by
Valentin
at
23:33
0
comments
Labels: hardware
2016-08-26
Decoupling
Замечательная идея: отсоединить I/O от конкретного протокола, скажем, HTTP.
Цитирую:
In a word: reusability. By implementing network protocols without any I/O and instead operating on bytes or text alone, libraries allow for reuse by other code regardless of their I/O decisions. In other words by leaving I/O out of the picture a network protocol library allows itself to be used by both synchronous and asynchronous I/O code. And by not simply abstracting out the I/O it allows users of the library to drive the network interactions themselves, not the network protocol library itself; not forcing I/O code to have to conform to a certain API provides the greatest flexibility for users of such low-level details such as network protocols. Working towards this unbinding of network protocols from I/O is very important as the Python community migrates from synchronous I/O code to using async/await for asynchronous I/O.
https://sans-io.readthedocs.io/
Не важно, как ты делаешь I/O, ты, главное, массив байтов или строку текста дай на вход и bob-your-uncle.
original post http://vasnake.blogspot.com/2016/08/decoupling.html
Posted by
Valentin
at
20:39
0
comments
Labels: python
Cartobonus/Картобонус
original post http://vasnake.blogspot.com/2016/08/cartobonus.html
Posted by
Valentin
at
20:26
0
comments
2016-08-17
produce a random BigInt and convert it to base 36
BigInt.probablePrime(100, util.Random).toString(36)
BigInt(128, util.Random) toString 36
Posted by
Valentin
at
23:49
0
comments
Labels: Book, programming, scala
BerkeleyX: CS190.1x Scalable Machine Learning, digest
Курс
BerkeleyX: CS190.1x Scalable Machine Learning
Posted by
Valentin
at
05:09
2
comments
2016-08-11
Machine Learning (Andrew Ng, Coursera, Stanford)
2016-08-04
Principles of Reactive Programming (Scala)
original post http://vasnake.blogspot.com/2016/08/principles-of-reactive-programming-scala.html
Posted by
Valentin
at
03:25
0
comments
Labels: course, functional programming, scala
2016-07-31
Dynamic Programming
Всё, что вы хотели знать про Dynamic Programming
-- brute-force, memoization, subproblems, guess, recursion.
Лекции от Erik Demaine (MIT)
https://youtu.be/ENyox7kNKeY
http://ocw.mit.edu/courses/electrical-engineering-and-computer-science/6-006-introduction-to-algorithms-fall-2011/lecture-videos/
В частности,
1. что такое memoization, почему так называется?
2. Почему Dynamic Programming, откуда такое название?
1: Memo pad, внесение заметок в memo pad -- memoization.
2: Ученый работал на вояк и не мог сказать, что занимается "исследованиями", поэтому придумал загадочный термин, чтобы генералы не доебались.
original post http://vasnake.blogspot.com/2016/07/dynamic-programming.html
2016-07-20
Spark 2
Apache Spark 2: DataFrames, Datasets, Streaming.
Серьезные изменения в скорости и возможностях
https://www.youtube.com/playlist?list=PL-x35fyliRwiz70bTSSK4HmOZ4JazCFUj
https://www.google.com/search?q=spark+2+dataframe+dataset+streaming
https://spark-summit.org/2016/schedule/
original post http://vasnake.blogspot.com/2016/07/spark-2.html
Posted by
Valentin
at
02:55
0
comments
2016-07-15
FP
Posted by
Valentin
at
03:21
0
comments
Labels: functional programming, video
2016-07-06
Подрезово-1
Сегодня устроили себе каталку в Подрезово - 1, на Пироговском водохранилище.
Я про это место ранее писал: http://vasnake.blogspot.com/2016/07/blog-post.html
На парковку пляжную, за шлагбаумом, пустили за 250 рублей. Деньги пошли вратарю на карман -- ни чека, ни карточки я не видел. Несмотря на это, подъехать поближе к воде не разрешили, даже на 5 минут для разгрузки/погрузки. Не положено.
Пришлось матчасть на горбу тащить метров 150.
Пляж хороший, но грязновато.
Прогноз был: юго-западный ветер 8-12 м/с. На самом деле было что-то вроде 5-10 м/с с редкими порывами до 12. Что хуже -- ветер на редкость рваный, порывы по нескольку секунд, тольком разогнаться не успеешь. Все руки себе оборвал.
Хреновая каталка получилась.
original post http://vasnake.blogspot.com/2016/07/1.html
Posted by
Valentin
at
19:58
0
comments
Labels: windsurfing
2016-07-04
Scala Type Classes
original post http://vasnake.blogspot.com/2016/07/scala-type-classes.html
Posted by
Valentin
at
20:40
0
comments
Labels: functional programming, scala
2016-07-02
About Typeclasses, Spark and other FP shit
Я просто оставлю это здесь.
Пара материалов, опубликованных в недельной подборке на 47 Degrees
http://www.47deg.com/blog/fp-news-update-week-of-7-01
Как люди мучаются без ducktyping: вот, придумали typeclasses для выхода на следующий уровень абстракции. Зато всё под контролем
https://speakerdeck.com/raulraja/typeclasses-tour
12 видеороликов про Спарк
The video presentations from Spark Summit this June
https://www.youtube.com/watch?list=PL-x35fyliRwiz70bTSSK4HmOZ4JazCFUj&v=1a4pgYzeFwE
original post http://vasnake.blogspot.com/2016/07/about-typeclasses-spark-and-other-fp.html
2016-07-01
Пара пляжей на Пироговском
На обоих виндсерфер может выйти на воду относительно легко.
А если одолеет шлагбаум, так и вовсе заипца.
https://maps.yandex.ru/?um=constructor:WaVdZ4EoSLnD3jjLMAjycx1l4Y0d-XtV&source=constructor
Posted by
Valentin
at
18:44
0
comments
Labels: windsurfing
Parallel computing: Amdahl's law
Закон Амдала ограничивает применимость параллельных вычислений.
И одно серъезное
Posted by
Valentin
at
17:34
0
comments
Labels: concurrent, video
2016-06-30
2,3 from 5: Functional Programming in Scala Specialization
Еще одна зарубка: сегодня закончил очередной курс.
Месяц назад на Курсере открылся новый сет:
Functional Programming in Scala Specialization
4 курса и финальный проект, на тему функционального программирования в целом и Scala в частности.
Первый и второй курс сета сделаны на основе старых
-- Functional Programming Principles in Scala
-- Principles of Reactive Programming
К сожалению, большая часть Principles of Reactive Programming в новый сет не вошла, только малая часть про монады, фьючеры и стримы/эвенты.
Но это не беда, я сохранил все материалы и, со временем, изучу их в подробностях.
Как бы то ни было, чтобы участвовать в пятой части сета, финальном проекте, надо успешно пройти четыре предварительных курса. Чем я и занялся.
На сегодняшний день пройдены 3 курса:
-- Functional Programming Principles in Scala (дайджест составлен)
-- Functional Program Design in Scala (дайджест будет)
-- Parallel programming (дайджест будет)
Это было непросто, за месяц пройти аж 3 курса. Только благодаря тому, что с первыми двумя я уже был знаком, удалось прорваться в финал и не порваться.
Теперь жду, когда начнут вещать четвертый курс: Big Data Analysis with Scala and Spark.
А чтобы время не терять, займусь дайджестами пройденного. Stay tuned.
original post http://vasnake.blogspot.com/2016/06/23-from-5-functional-programming-in.html
Posted by
Valentin
at
19:52
0
comments
Labels: course, functional programming, scala
2016-06-25
Пироговское водохранилище, Марабу
Съездили сегодня на разведку, на Пироговское водохранилище, Ореховая бухта, в клуб Марабу.
Заценить, как-что-почем в плане виндсерфинга.
Широта 55°58′26″N (55.973891) Долгота 37°39′52″E (37.664384)
https://yandex.ru/maps/-/CVXNB059
https://goo.gl/MnturU
Последний километр дороги -- полный пиздей подвеске, ямы, бетонные плиты вкривь и вкось.
Есть место, где при хорошем дожде дорогу может подмыть, есть риск провала.
После шлагбаума -- грунтовка терпимого качества, пока сухо.
На шлагбауме могут потребовать 200 рублей. Местные говорят, что можно бесплатно, если
"я везу оборудование в Марабу, туда и сразу обратно".
Удобного выхода к воде нет, надо лазить по горе вверх-вниз. Есть лестницы.
Все заросло деревьями, кустами, развернуться негде.
Где вооружаться -- неясно, то ли на мостках, то ли в лесу.
Стартовать с мостков (и возвращаться) -- сомнительное удовольствие, скорее всего парус будет порван.
Хранилка: 5000 руб/мес, паруса не в контейнере а под навесом. WTF!
http://www.marabou.ru/part.php?prt=service
На воде довольно много народу всякого.
Плюсы? Недалеко от нерезиновой, большой водоем, нет комаров, рядом цивилизация: кафе, яхт-клуб, все дела.
Вменяемые цены на аренду оборудования.
Фоток не сделал, что там фотать... вот, в тырнетах нашлось
Posted by
Valentin
at
21:29
2
comments
Labels: windsurfing
2016-06-01
super, MRO
Python, всё, что вам надо знать про функцию 'super' и Method Resolution Order
цитата
The super built-in function was introduced way back in Python 2.2. The super function will return a proxy object that will delegate method calls to a parent or sibling class of type. If that was a little unclear, what it allows you to do is access inherited methods that have been overridden in a class
...
class MyParentClass(object): def __init__(self): pass class SubClass(MyParentClass): def __init__(self): MyParentClass.__init__(self)
class SubClass(MyParentClass): def __init__(self): super(SubClass, self).__init__()Python 3 simplified this a bit. Let’s take a look:
class MyParentClass(): def __init__(self): pass class SubClass(MyParentClass): def __init__(self): super()
...super knows how to interpret the MRO and it stores this information in the following magic propertie: __thisclass__ and __self_class__. Let’s look at an example:
class Base(): def __init__(self): s = super() print(s.__thisclass__) print(s.__self_class__) s.__init__() class SubClass(Base): pass sub = SubClass()http://www.blog.pythonlibrary.org/2016/05/25/python-201-super/
И про MRO
цитата
Everything started with a post by Samuele Pedroni to the Python development mailing list. In his post, Samuele showed that the Python 2.2 method resolution order is not monotonic and he proposed to replace it with the C3 method resolution order. Guido agreed with his arguments and therefore now Python 2.3 uses C3. The C3 method itself has nothing to do with Python, since it was invented by people working on Dylan ...
The list of the ancestors of a class C, including the class itself, ordered from the nearest ancestor to the furthest, is called the class precedence list or the linearization of C.
...
The Method Resolution Order (MRO) is the set of rules that construct the linearization. In the Python literature, the idiom "the MRO of C" is also used as a synonymous for the linearization of the class C.
...
A MRO is monotonic when the following is true: if C1 precedes C2 in the linearization of C, then C1 precedes C2 in the linearization of any subclass of C. Otherwise, the innocuous operation of deriving a new class could change the resolution order of methods, potentially introducing very subtle bugs.
...
C3 MRO the linearization of C is the sum of C plus the merge of the linearizations of the parents and the list of the parents.
L[C(B1 ... BN)] = C + merge(L[B1] ... L[BN], B1 ... BN)
...
take the head of the first list, i.e L[B1][0]; if this head is not in the tail of any of the other lists, then add it to the linearization of C and remove it from the lists in the merge, otherwise look at the head of the next list and take it, if it is a good head. Then repeat the operation until all the class are removed or it is impossible to find good heads. In this case, it is impossible to construct the merge, Python 2.3 will refuse to create the class C and will raise an exception.
...
Guido points out in his essay that the classic MRO is not so bad in practice, since one can typically avoids diamonds for classic classes. But all new style classes inherit from object, therefore diamonds are unavoidable and inconsistencies shows up in every multiple inheritance graph.
https://www.python.org/download/releases/2.3/mro/
original post http://vasnake.blogspot.com/2016/06/super-mro.html
Posted by
Valentin
at
21:45
0
comments















