Tag Archives: 90

Managing AWS Lambda Function Concurrency

Post Syndicated from Chris Munns original https://aws.amazon.com/blogs/compute/managing-aws-lambda-function-concurrency/

One of the key benefits of serverless applications is the ease in which they can scale to meet traffic demands or requests, with little to no need for capacity planning. In AWS Lambda, which is the core of the serverless platform at AWS, the unit of scale is a concurrent execution. This refers to the number of executions of your function code that are happening at any given time.

Thinking about concurrent executions as a unit of scale is a fairly unique concept. In this post, I dive deeper into this and talk about how you can make use of per function concurrency limits in Lambda.

Understanding concurrency in Lambda

Instead of diving right into the guts of how Lambda works, here’s an appetizing analogy: a magical pizza.
Yes, a magical pizza!

This magical pizza has some unique properties:

  • It has a fixed maximum number of slices, such as 8.
  • Slices automatically re-appear after they are consumed.
  • When you take a slice from the pizza, it does not re-appear until it has been completely consumed.
  • One person can take multiple slices at a time.
  • You can easily ask to have the number of slices increased, but they remain fixed at any point in time otherwise.

Now that the magical pizza’s properties are defined, here’s a hypothetical situation of some friends sharing this pizza.

Shawn, Kate, Daniela, Chuck, Ian and Avleen get together every Friday to share a pizza and catch up on their week. As there is just six of them, they can easily all enjoy a slice of pizza at a time. As they finish each slice, it re-appears in the pizza pan and they can take another slice again. Given the magical properties of their pizza, they can continue to eat all they want, but with two very important constraints:

  • If any of them take too many slices at once, the others may not get as much as they want.
  • If they take too many slices, they might also eat too much and get sick.

One particular week, some of the friends are hungrier than the rest, taking two slices at a time instead of just one. If more than two of them try to take two pieces at a time, this can cause contention for pizza slices. Some of them would wait hungry for the slices to re-appear. They could ask for a pizza with more slices, but then run the same risk again later if more hungry friends join than planned for.

What can they do?

If the friends agreed to accept a limit for the maximum number of slices they each eat concurrently, both of these issues are avoided. Some could have a maximum of 2 of the 8 slices, or other concurrency limits that were more or less. Just so long as they kept it at or under eight total slices to be eaten at one time. This would keep any from going hungry or eating too much. The six friends can happily enjoy their magical pizza without worry!

Concurrency in Lambda

Concurrency in Lambda actually works similarly to the magical pizza model. Each AWS Account has an overall AccountLimit value that is fixed at any point in time, but can be easily increased as needed, just like the count of slices in the pizza. As of May 2017, the default limit is 1000 “slices” of concurrency per AWS Region.

Also like the magical pizza, each concurrency “slice” can only be consumed individually one at a time. After consumption, it becomes available to be consumed again. Services invoking Lambda functions can consume multiple slices of concurrency at the same time, just like the group of friends can take multiple slices of the pizza.

Let’s take our example of the six friends and bring it back to AWS services that commonly invoke Lambda:

  • Amazon S3
  • Amazon Kinesis
  • Amazon DynamoDB
  • Amazon Cognito

In a single account with the default concurrency limit of 1000 concurrent executions, any of these four services could invoke enough functions to consume the entire limit or some part of it. Just like with the pizza example, there is the possibility for two issues to pop up:

  • One or more of these services could invoke enough functions to consume a majority of the available concurrency capacity. This could cause others to be starved for it, causing failed invocations.
  • A service could consume too much concurrent capacity and cause a downstream service or database to be overwhelmed, which could cause failed executions.

For Lambda functions that are launched in a VPC, you have the potential to consume the available IP addresses in a subnet or the maximum number of elastic network interfaces to which your account has access. For more information, see Configuring a Lambda Function to Access Resources in an Amazon VPC. For information about elastic network interface limits, see Network Interfaces section in the Amazon VPC Limits topic.

One way to solve both of these problems is applying a concurrency limit to the Lambda functions in an account.

Configuring per function concurrency limits

You can now set a concurrency limit on individual Lambda functions in an account. The concurrency limit that you set reserves a portion of your account level concurrency for a given function. All of your functions’ concurrent executions count against this account-level limit by default.

If you set a concurrency limit for a specific function, then that function’s concurrency limit allocation is deducted from the shared pool and assigned to that specific function. AWS also reserves 100 units of concurrency for all functions that don’t have a specified concurrency limit set. This helps to make sure that future functions have capacity to be consumed.

Going back to the example of the consuming services, you could set throttles for the functions as follows:

Amazon S3 function = 350
Amazon Kinesis function = 200
Amazon DynamoDB function = 200
Amazon Cognito function = 150
Total = 900

With the 100 reserved for all non-concurrency reserved functions, this totals the account limit of 1000.

Here’s how this works. To start, create a basic Lambda function that is invoked via Amazon API Gateway. This Lambda function returns a single “Hello World” statement with an added sleep time between 2 and 5 seconds. The sleep time simulates an API providing some sort of capability that can take a varied amount of time. The goal here is to show how an API that is underloaded can reach its concurrency limit, and what happens when it does.
To create the example function

  1. Open the Lambda console.
  2. Choose Create Function.
  3. For Author from scratch, enter the following values:
    1. For Name, enter a value (such as concurrencyBlog01).
    2. For Runtime, choose Python 3.6.
    3. For Role, choose Create new role from template and enter a name aligned with this function, such as concurrencyBlogRole.
  4. Choose Create function.
  5. The function is created with some basic example code. Replace that code with the following:

import time
from random import randint
seconds = randint(2, 5)

def lambda_handler(event, context):
time.sleep(seconds)
return {"statusCode": 200,
"body": ("Hello world, slept " + str(seconds) + " seconds"),
"headers":
{
"Access-Control-Allow-Headers": "Content-Type,X-Amz-Date,Authorization,X-Api-Key,X-Amz-Security-Token",
"Access-Control-Allow-Methods": "GET,OPTIONS",
}}

  1. Under Basic settings, set Timeout to 10 seconds. While this function should only ever take up to 5-6 seconds (with the 5-second max sleep), this gives you a little bit of room if it takes longer.

  1. Choose Save at the top right.

At this point, your function is configured for this example. Test it and confirm this in the console:

  1. Choose Test.
  2. Enter a name (it doesn’t matter for this example).
  3. Choose Create.
  4. In the console, choose Test again.
  5. You should see output similar to the following:

Now configure API Gateway so that you have an HTTPS endpoint to test against.

  1. In the Lambda console, choose Configuration.
  2. Under Triggers, choose API Gateway.
  3. Open the API Gateway icon now shown as attached to your Lambda function:

  1. Under Configure triggers, leave the default values for API Name and Deployment stage. For Security, choose Open.
  2. Choose Add, Save.

API Gateway is now configured to invoke Lambda at the Invoke URL shown under its configuration. You can take this URL and test it in any browser or command line, using tools such as “curl”:


$ curl https://ofixul557l.execute-api.us-east-1.amazonaws.com/prod/concurrencyBlog01
Hello world, slept 2 seconds

Throwing load at the function

Now start throwing some load against your API Gateway + Lambda function combo. Right now, your function is only limited by the total amount of concurrency available in an account. For this example account, you might have 850 unreserved concurrency out of a full account limit of 1000 due to having configured a few concurrency limits already (also the 100 concurrency saved for all functions without configured limits). You can find all of this information on the main Dashboard page of the Lambda console:

For generating load in this example, use an open source tool called “hey” (https://github.com/rakyll/hey), which works similarly to ApacheBench (ab). You test from an Amazon EC2 instance running the default Amazon Linux AMI from the EC2 console. For more help with configuring an EC2 instance, follow the steps in the Launch Instance Wizard.

After the EC2 instance is running, SSH into the host and run the following:


sudo yum install go
go get -u github.com/rakyll/hey

“hey” is easy to use. For these tests, specify a total number of tests (5,000) and a concurrency of 50 against the API Gateway URL as follows(replace the URL here with your own):


$ ./go/bin/hey -n 5000 -c 50 https://ofixul557l.execute-api.us-east-1.amazonaws.com/prod/concurrencyBlog01

The output from “hey” tells you interesting bits of information:


$ ./go/bin/hey -n 5000 -c 50 https://ofixul557l.execute-api.us-east-1.amazonaws.com/prod/concurrencyBlog01

Summary:
Total: 381.9978 secs
Slowest: 9.4765 secs
Fastest: 0.0438 secs
Average: 3.2153 secs
Requests/sec: 13.0891
Total data: 140024 bytes
Size/request: 28 bytes

Response time histogram:
0.044 [1] |
0.987 [2] |
1.930 [0] |
2.874 [1803] |∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎
3.817 [1518] |∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎
4.760 [719] |∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎
5.703 [917] |∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎
6.647 [13] |
7.590 [14] |
8.533 [9] |
9.477 [4] |

Latency distribution:
10% in 2.0224 secs
25% in 2.0267 secs
50% in 3.0251 secs
75% in 4.0269 secs
90% in 5.0279 secs
95% in 5.0414 secs
99% in 5.1871 secs

Details (average, fastest, slowest):
DNS+dialup: 0.0003 secs, 0.0000 secs, 0.0332 secs
DNS-lookup: 0.0000 secs, 0.0000 secs, 0.0046 secs
req write: 0.0000 secs, 0.0000 secs, 0.0005 secs
resp wait: 3.2149 secs, 0.0438 secs, 9.4472 secs
resp read: 0.0000 secs, 0.0000 secs, 0.0004 secs

Status code distribution:
[200] 4997 responses
[502] 3 responses

You can see a helpful histogram and latency distribution. Remember that this Lambda function has a random sleep period in it and so isn’t entirely representational of a real-life workload. Those three 502s warrant digging deeper, but could be due to Lambda cold-start timing and the “second” variable being the maximum of 5, causing the Lambda functions to time out. AWS X-Ray and the Amazon CloudWatch logs generated by both API Gateway and Lambda could help you troubleshoot this.

Configuring a concurrency reservation

Now that you’ve established that you can generate this load against the function, I show you how to limit it and protect a backend resource from being overloaded by all of these requests.

  1. In the console, choose Configure.
  2. Under Concurrency, for Reserve concurrency, enter 25.

  1. Click on Save in the top right corner.

You could also set this with the AWS CLI using the Lambda put-function-concurrency command or see your current concurrency configuration via Lambda get-function. Here’s an example command:


$ aws lambda get-function --function-name concurrencyBlog01 --output json --query Concurrency
{
"ReservedConcurrentExecutions": 25
}

Either way, you’ve set the Concurrency Reservation to 25 for this function. This acts as both a limit and a reservation in terms of making sure that you can execute 25 concurrent functions at all times. Going above this results in the throttling of the Lambda function. Depending on the invoking service, throttling can result in a number of different outcomes, as shown in the documentation on Throttling Behavior. This change has also reduced your unreserved account concurrency for other functions by 25.

Rerun the same load generation as before and see what happens. Previously, you tested at 50 concurrency, which worked just fine. By limiting the Lambda functions to 25 concurrency, you should see rate limiting kick in. Run the same test again:


$ ./go/bin/hey -n 5000 -c 50 https://ofixul557l.execute-api.us-east-1.amazonaws.com/prod/concurrencyBlog01

While this test runs, refresh the Monitoring tab on your function detail page. You see the following warning message:

This is great! It means that your throttle is working as configured and you are now protecting your downstream resources from too much load from your Lambda function.

Here is the output from a new “hey” command:


$ ./go/bin/hey -n 5000 -c 50 https://ofixul557l.execute-api.us-east-1.amazonaws.com/prod/concurrencyBlog01
Summary:
Total: 379.9922 secs
Slowest: 7.1486 secs
Fastest: 0.0102 secs
Average: 1.1897 secs
Requests/sec: 13.1582
Total data: 164608 bytes
Size/request: 32 bytes

Response time histogram:
0.010 [1] |
0.724 [3075] |∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎
1.438 [0] |
2.152 [811] |∎∎∎∎∎∎∎∎∎∎∎
2.866 [11] |
3.579 [566] |∎∎∎∎∎∎∎
4.293 [214] |∎∎∎
5.007 [1] |
5.721 [315] |∎∎∎∎
6.435 [4] |
7.149 [2] |

Latency distribution:
10% in 0.0130 secs
25% in 0.0147 secs
50% in 0.0205 secs
75% in 2.0344 secs
90% in 4.0229 secs
95% in 5.0248 secs
99% in 5.0629 secs

Details (average, fastest, slowest):
DNS+dialup: 0.0004 secs, 0.0000 secs, 0.0537 secs
DNS-lookup: 0.0002 secs, 0.0000 secs, 0.0184 secs
req write: 0.0000 secs, 0.0000 secs, 0.0016 secs
resp wait: 1.1892 secs, 0.0101 secs, 7.1038 secs
resp read: 0.0000 secs, 0.0000 secs, 0.0005 secs

Status code distribution:
[502] 3076 responses
[200] 1924 responses

This looks fairly different from the last load test run. A large percentage of these requests failed fast due to the concurrency throttle failing them (those with the 0.724 seconds line). The timing shown here in the histogram represents the entire time it took to get a response between the EC2 instance and API Gateway calling Lambda and being rejected. It’s also important to note that this example was configured with an edge-optimized endpoint in API Gateway. You see under Status code distribution that 3076 of the 5000 requests failed with a 502, showing that the backend service from API Gateway and Lambda failed the request.

Other uses

Managing function concurrency can be useful in a few other ways beyond just limiting the impact on downstream services and providing a reservation of concurrency capacity. Here are two other uses:

  • Emergency kill switch
  • Cost controls

Emergency kill switch

On occasion, due to issues with applications I’ve managed in the past, I’ve had a need to disable a certain function or capability of an application. By setting the concurrency reservation and limit of a Lambda function to zero, you can do just that.

With the reservation set to zero every invocation of a Lambda function results in being throttled. You could then work on the related parts of the infrastructure or application that aren’t working, and then reconfigure the concurrency limit to allow invocations again.

Cost controls

While I mentioned how you might want to use concurrency limits to control the downstream impact to services or databases that your Lambda function might call, another resource that you might be cautious about is money. Setting the concurrency throttle is another way to help control costs during development and testing of your application.

You might want to prevent against a function performing a recursive action too quickly or a development workload generating too high of a concurrency. You might also want to protect development resources connected to this function from generating too much cost, such as APIs that your Lambda function calls.

Conclusion

Concurrent executions as a unit of scale are a fairly unique characteristic about Lambda functions. Placing limits on how many concurrency “slices” that your function can consume can prevent a single function from consuming all of the available concurrency in an account. Limits can also prevent a function from overwhelming a backend resource that isn’t as scalable.

Unlike monolithic applications or even microservices where there are mixed capabilities in a single service, Lambda functions encourage a sort of “nano-service” of small business logic directly related to the integration model connected to the function. I hope you’ve enjoyed this post and configure your concurrency limits today!

Пет мита за електронното гласуване

Post Syndicated from Bozho original https://blog.bozho.net/blog/3004

Тази седмица ЦИК ще направи демонстрация на електронно гласуване в рамките на проекта, който преди малко повече от година заложихме в пътната карта за електронно управление. На „дистанционно електронно гласуване“, ако трябва да сме коректни – терминологията не е унифицирана, и често само „електронно гласуване“ може да значи и „машинно“. Та във връзка с раздвижването по темата, по медиите канят знайни и незнайни хора (сред които и уважавани експерти) да коментират. Случват се и разни събития/кръгли маси/конференции по темата, на някои от които присъствам.

Това, което чувам са доста неинформирани мнения и разпространяване и преповтаряне на митове. Затова реших да си избера пет мита, които говорещите против електронното гласуване разпространяват. Винаги дяволът е в детайлите, а с една подхвърлена полуистина в ефира се създават настроения в обществото.

„Много държави го забраниха или се отказаха“ – тук посланието е „всички се отказват от него, ние къде сме тръгнали“. Разбира се, това е невярно. Половината от държавите, които се изреждат, не са и опитвали дистанционно електронно гласуване, а само машинно. И поради машини „черни кутии“ (със затворен код) и висока цена, наистина се отказват от тях. Но когато говорим за дистанционно електронно гласуване, картинката е по-различна. Експертимент, след който не е пристъпено към реално гласуване, е имало в Норвегия. Причината за да не се пристъпи нататък? В официалния доклад техническият проблем е тривиален – функцията за генериране на случайни числа не е била добра. Но по-важният фактор е, че на власт е дошла опозицията (социалистическата партия) и тя е спряла проекта на предишното правителство. Германският Конституционен съд пък е взел решение – експерименти е нямало, та докато нашия Конституционен съд не вземе такова решение за действащия изборен кодекс, нямаме такъв проблем (има решения за предишни текстове в кодекса, но това е по вина на текстовете – новите адресират мотивите на съда). Холандия е забранила машини, не дистанционно електронно, и то по много специфични за конкретната машина съображения, така че не е по темата с дистанционно електронно. „Франция го забрани/се отказа“ също не е вярно. Франция позволява дистанционно електронно гласуване от 2012-та, но конкретно на тазгодишните избори реши да не позволява този канал за гласуване, заради потенциалната руска намеса. Това не значи, че на следващите избори няма да имат електронно гласуване, нито, че решението е било мотивирано с нещо различно от страх. В нашия изборен кодекс тази опция е предвидена – ЦИК може да вземе решение да не прилага дистанционно електронно гласуване, ако мотивира това с технически доклад за неизбежни и непосредствени рискове. Това обаче не е „винаги“. Та, като някой тръгне да ви изрежда държави, които го били „забранили“…не приемайте това като чиста истина.

„Само Естония гласува електронно“ – на национални избори – Естония и Франция (за живеещите извън Франция), но няколко швейцарски кантона гласуват електронно, един австралийски щат (Нови Южен Уелс, в който е Сидни), Аляска и общини на различни места по света, в т.ч. Мексико Сити. Това, разбира се, не е аргумент сам по себе си – другите държави имат много различен дневен ред и изборна ситуация. Структурата на нашето население е специфична – немалка част от него е в чужбина, а това не може да се каже за много други европейски държави. Според доклад на ООН 14% от българите живеят в чужбина. Другите държави са нямали референдум за електронно гласуване, нямат и такъв проблем с купен и контролиран вот, имат по-висока избирателна активност и т.н. Много други държави обаче позволяват гласуване по пощата, което е аналоговото решение на сходен проблем. На нашите пощи обаче не може да се разчита, нито на процеса, в който се отварят пликовете.

„Естонското беше хакнато“ – това е съвсем невярно. Базира се на един доклад на Алекс Халдерман, който критикува някои аспекти на оперативната сигурност (т.е. практиките на длъжностните лица при провеждане на изборите). Отговорът на естонската агенция за електронно управление е доста ясен – нямало е манипулации, а оперативните практики се подобряват постоянно. И имайки предвид, че Русия организира сериозна кибератака срещу Естония преди десетина години (във връзка с премахване на паметник), липсата на проблеми след над 10 години електронно гласуване е показателна. Освен докладът на Халдерман, тази година стана ясно, че производителят на чипа в естонските лични карти е допуснал грешка, заради която те не са толкова сигурни, колкото сме си мислели. Това не засяга всички естонски лични карти, а засегнатите се подменят. Ако по това време имаше електронно гласуване, то просто щеше да бъде спряно и хората щяха да бъдат уведомени да отидат да гласуват на хартия, както позволява естонският изборен кодекс, и съответно нашият (в който сме заимствали от естонския). Т.е. не, естонското не е хакнато, а при установяване на нерешим проблем, избирателната комисия има правото да го спре и да прати хората да гласуват на хартия (защото електронното е няколко дни преди изборния ден).

„Ще улесни купуването на гласове“ – не, няма. По много причини, някои технологични, други – пазарни. Кодексът предвижда предварителна регистрация за електронно гласуване, предвижда и двустепенна оторизация (т.е. използване на мобилен телефон освен електронната личната карта), предвижда технически мерки за ограничаване на много последователни гласувания от един компютър. И докато всички тези неща са заобиколими със стройна организация и технически умения на купуващите, това ще бъде много по-трудно, отколкото просто да купиш гласовете и да пратиш хората да гласуват на хартия в секция. Да сравним правенето на списък и чакането пред секция на неквалифициран персонал (най-често цигански тартор), със зачистване на регистри/смяна на мак адреси, събиране на лични карти И телефони, и то за период от няколко дни, за да не може купеният да си промени гласа след това. И отгоре на всичко, в ЦИК и МВР ще има карта на регистрираните за електронно гласуване, така че ако в рискови райони има концентрация, да бъде направена проверка. Т.е. бариерите пред купуването (а и контролирането) на гласове при електронното гласуване са много повече от тези при хартиеното. Сценарият „ще им събере личните карти и ще напуска гласове“ звучи възможен само ако човек не познава подробностите.

„Трябва да има първо електронно управление и чак тогава електронно гласуване“ – бившият председател на естонската комисия за електронно гласуване ми разказа интересна история. Преди първото електронно гласуване (2005-та) броят активно използвани електронни лични карти е бил около пет хиляди. Да, Естония ги въвежда 2001-ва, но докато хората ги получат, докато започнат да ползват услуги, докато се появяват услуги, минават няколко години. На първото електронно гласуване онлайн гласуват 9300 души, т.е. почти два пъти повече. Електронното гласуване е катализатор на електронното управление и няма причина да чакаме да си вържем всички регистри, за да имаме електронно гласуване. Единствената предпоставка е електронната идентификация (електронна лична карта или друго средство). За съжаление, там правителството доста изостава от планираните срокове (това лято отложи електронната лична карта с още една година).

Почти всичко това съм го разказал в детайли в лекцията си от преди две години. Но детайлите са скучни и затормозяващи и затова пръскането на митове в ефира е по-ефективно и по-въздействащо.

Аз също съм против прибързаното въвеждане на технология в толкова важен процес като изборите, и съм го казвал неведнъж. Но референдумът беше 2015-та, а първите обвързващи електронни избори трябва да са 2019-та. Три години и половина не е „прибързване“. Затова има пътна карта, има проект, има изборен кодекс, има предвидени симулации и експерименти.

Но линията, която в момента започва все по-отчетливо да се появява е „абе, то не е сигурно, дай да го отложим за неопределено време“. Иска ми се да я отдам на неиформираност, а не на конспирация. И когато януари 2019-та стигнем до момента на вземане на решение „спазваме или изборния кодекс или не“, силно се надявам решението да бъде доста по-информирано от простото цитиране на горните митове.

Колективно управление на права: иск на ЕК срещу България

Post Syndicated from nellyo original https://nellyo.wordpress.com/2017/12/10/2014-26-ip/

На  7 декември 2017 r. стана известно решението на ЕК да предяви иск пред Съда на ЕС срещу България, Испания, Люксембург и Румъния поради липса на уведомление за цялостно транспониране в националното законодателство  на разпоредбите на ЕС в областта на колективното управление на авторското право и сродните му права и на многотериториалното лицензиране на правата върху музикални произведения за използване онлайн, т. е. транспониране на Директивата относно колективното управление на правата (Директива 2014/26/ЕС), което  е предвидено да се извърши до 10 април 2016 г. Процедурите за нарушение са открити през май 2016 г. , но Комисията все още не е получила уведомление, че са предприети необходимите мерки за транспониране на директивата.

Комисията реагира при липса на уведомление, при частично или неправилно транспониране.  По-нататък в съобщението се казва, че

Комисията призовава Съда да наложи финансови санкции на тези четири държави (България — 19 121,60 EUR на ден, Испания — 123 928,64 EUR на ден, Люксембург — 12 920,00 EUR на ден и Румъния — 42 377,60 EUR на ден).

Относно процедурата

Макар че по-известната реакция е Комисията да предложи финансова санкция (едва) в случай на неизпълнение на решение на Съда,  с нововъведение от Договора от Лисабон (чл.260, нов параграф 3 ДФЕС)  се предвижда следното: „Когато Комисията сезира Съда на Европейския съюз с иск по силата на член 258, тъй като счита, че тази държава  не е изпълнила задължението си да съобщи за мерките за транспониране на директива, приета съгласно определена законодателна процедура, тя може, ако счете за уместно, да определи размера на еднократно платимата сума или периодичната имуществена санкция, която тази държава трябва да заплати, и която според нея е съобразена с обстоятелствата.

Ако Съдът на Европейския съюз установи, че има неизпълнение на горепосоченото задължение, той може да наложи на тази държава  да заплати еднократно платимата сума или периодичната имуществена санкция, в рамките на размера, определен от Комисията. Задължението за плащане влиза в сила на датата, определена в решението на Съда на Европейския съюз.“

Както се посочва и в SEC(2010) 1371 окончателен, този параграф създава изцяло нов инструмент. Комисията може да предложи на Съда на Европейския съюз  още от момента на подаване на иска си за установяване на неизпълнение на задължение по силата на член 258 ДФЕС  да наложи заплащането на еднократно платимата сума или на периодичната имуществена санкция със същото решение, с което се установява неизпълнението от страна на държава-членка на задължението ѝ да съобщи за мерки за транспонирането на директива, приета съгласно законодателната процедура.

Комисията може да използва новата възможност  „ако счете  за уместно“ – какъвто очевидно е нашият случай.

Комисията вече е прилагала чл.260, параграф 3 ДФЕС по отношение на България – по дело С-203/13 искането на ЕК е Съдът освен отстраняване на допуснатите нарушения в законодателство, да наложи на Република България в съответствие c член 260, параграф 3 от ДФЕС и имуществена санкция в размер на 8448 евро на ден за всяка частично транспонирана директива  в областта на енергетиката.  Комисията  впоследствие е оттеглила иска си в резултат на поведението на Република България, която е предприела необходимите за изпълнение на задълженията си мерки едва след предявяването на иска.

По същество

Очаква въвеждане  Директива относно колективното управление на правата (Директива 2014/26/ЕС)

Директивата  има за цел да подобри начина, по който се управляват всички организации за колективно управление чрез създаване на общи стандарти за управление, прозрачност и финансова дисциплина. С нея също така се определят общи стандарти за многотериториалното лицензиране на правата върху музикални произведения за използване онлайн на вътрешния пазар. Директивата относно колективното управление на правата е важна част от законодателството за авторското право в Европа. Всички организации за колективно управление трябва да подобрят своите стандарти за управление и за прозрачност.

В Румъния според ЕК има неправилно прилагане – законодателството на ЕС предвижда, че авторите могат да разрешават или забраняват разгласяването пред публика на своите произведения, но в Румъния авторите нямат друг избор, освен да оставят управлението на своето право на публично разгласяване на музикални произведения на организация за колективно управление. Това води до лишаване от изключителното авторско право на публично разгласяване, което, по мнението на Комисията, не е оправдано по смисъла на правото на ЕС.  Другите три държави, вкл. България,  не са уведомили ЕК за транспониране.

Рискът от санкция и необходимостта от експедитивност не намалява изискванията към националния законодателен процес за обоснованост, балансираност, съобразяване на различните интереси. Става дума за стандарти за прозрачност на организациите за колективно управление – и това прави националната мярка особено важна.

Събщение за медиите

Filed under: Uncategorized Tagged: съд на ес

Три билборда извън града – по Маклуън

Post Syndicated from nellyo original https://nellyo.wordpress.com/2017/12/09/three_billboards/

 

.

Последният засега филм на Мартин Макдона Три билборда извън града  (оригинално заглавие  Three Billboards Outside Ebbing, Missouri)  беше показан и в София. Филмът вече е взел наградата на публиката в Сан Себастиан и Торонто, наградата за най-добър сценарий във Венеция и две награди BIFA.

Главната героиня е Милдред Хейс. Живее в малък град  в Мисури, разведена, майка на син и дъщеря,  преживяла преди месеци огромна лична трагедия. Дъщеря й Анжела, в трудната гимназиална възраст, една вечер е изнасилена и убита. Месеци наред убиецът остава неизвестен, мъката не отстъпва, но се засилва гневът от липсата на справедливост и правосъдие.  На входа на града, покрай магистралата, има три изоставени билборда – и филмът започва с  решението на  Милдред да ги наеме, за да постави директно и видимо въпросите си  към хората, от които очаква действие – и лично към шефа на полицията : какво правиш, за да разкриеш престъплението? Въпросите  от билбордовете  – както и се очаква – привличат вниманието  на местната полиция, на телевизията,  на хората от града.

Какво казва законът, пита Милдред Хейс в началото, какво можеш и какво не можеш да напишеш на билборд?  Билбордовете са самостоятелен герой във филма: те движат действието, агресията към майката прелива в агресия  към билбордовете, подкрепата за майката се изразява в подкрепа за нейните въпроси на билбордовете, медията е съобщението*.  Ако в Ани Хол Маклуън се появява на екрана лично,   Три билборда извън града  е филмова реализация на идеите на Маклуън:  “Всяка медия застава между нас и реалността и въздейства върху начина ни на възприемане на света.”

Ролята на майката е поверена на Франсис Масдорманд, носителка на Оскар за ролята си във Фарго  на братята Джоел и Итън Коен. Макдорманд е съпруга на Джоел Коен от 1984 г.  и това като че ли по особен начин има отношение и към играта й в този филм на Макдона.  Може би не – но така или иначе вече писаха, че съсредоточената отдаденост, съчетана с пълна липса на актьорска суета, правят  Франсис Масдорманд  претендент за втори Оскар.

Както и наградите показват, в основата на успеха е текстът на Макдона.  Историята е пълна с обрати   и в края на филма трудно можем да се посочи  отрицателен герой – напълно отрицателен герой липсва,  героите показват различни страни от характера си в неочаквани развития. Конфликтът, разгърнат чрез билбордовете, е с местния полицейски шеф – който  на практика е престанал да търси убиеца, но пък го  е търсил добросъвестно – според собствените си разбирания, просто засега няма резултат  – и, за съжаление, е на път да си отиде от тежка болест. Какво може да направи? – Ако аз бях на твое място, бих направила база с ДНК за всеки мъж  в тази страна още от раждането му, и като стане нещо – установява се със сигурност – и смърт, казва майката.  – Това със сигурност не се позволява  от законите за правата на човека, обяснява полицаят, и точно в този момент той изглежда прав. Милдред Хейс също има грешки – може би и вини   – в трудните отношения майка – дъщеря, може би Анжела е щяла да остане  жива, ако майката с  търпение беше намирала път към нея: става ясно, че отношенията им са били обтегнати и скоро преди убийството дъщерята е искала да се премести да живее при баща си. Обтегнати отношения не заради липса на любов, а заради моментна небрежност или липса на внимание, никой не е съвършен – но само някои плащат толкова висока цена.

По подобен начин се развива и образът на полицая Диксън, класически расист и насилник, власт, облечена в сила. Още ли мъчиш негри, Диксън, пита майката в началото на филма. – Не негри, а цветнокожи, отговаря Диксън (известна фраза и от Ръкомахане в Спокан) –  и след известна пауза добавя – и не ги мъча.  Мъчи ги, филмът показва сцени на насилие, но ето, Диксън случайно чува непознат мъж да споделя, че е участвал в изнасилване – и от този момент се променя,  проявява изобретателност, рискува, за да получи ДНК от заподозрения – и  започва да се държи наистина като полицай, все пак повелята  е  да служи и да защитава.

Филмът не дава отговори, не знаем дали в далечината се вижда правосъдие за убитото момиче, но на финала камерата  проследява удивителна двойка – Милдред Хейс и Диксън, заели се с установяване на истината   – ако не за дъщерята на Милдред, то може би за друго насилие. Как ще продължи историята? Ще видим, ще решим по пътя.

Звучи и като отворен финал за Америка, за американската действителност. Ще решим по пътя.

Прекрасен филм, а най-хубавото е, че със сигурност за другите зрители важни ще се окажат други послания, те ще открият друго там. Отново време за Маклуън: “Как е възможно един поет като Елиът да заяви: Никога не съм мислил така, но това съм искал да кажа, след като вие сте го открили там. Ето това е моят начин на мислене по повод реакциите на критиката.”

*

Маршал Маклуън – исках да сложа връзка към статията за Маклуън в  българската Уикипедия – с удивление виждам, че няма статия, но поне има два реда за Медията е съобщението.

Filed under: Uncategorized

Looking Forward to 2018

Post Syndicated from Let's Encrypt - Free SSL/TLS Certificates original https://letsencrypt.org//2017/12/07/looking-forward-to-2018.html

Let’s Encrypt had a great year in 2017. We more than doubled the number of active (unexpired) certificates we service to 46 million, we just about tripled the number of unique domains we service to 61 million, and we did it all while maintaining a stellar security and compliance track record. Most importantly though, the Web went from 46% encrypted page loads to 67% according to statistics from Mozilla – a gain of 21% in a single year – incredible. We’re proud to have contributed to that, and we’d like to thank all of the other people and organizations who also worked hard to create a more secure and privacy-respecting Web.

While we’re proud of what we accomplished in 2017, we are spending most of the final quarter of the year looking forward rather than back. As we wrap up our own planning process for 2018, I’d like to share some of our plans with you, including both the things we’re excited about and the challenges we’ll face. We’ll cover service growth, new features, infrastructure, and finances.

Service Growth

We are planning to double the number of active certificates and unique domains we service in 2018, to 90 million and 120 million, respectively. This anticipated growth is due to continuing high expectations for HTTPS growth in general in 2018.

Let’s Encrypt helps to drive HTTPS adoption by offering a free, easy to use, and globally available option for obtaining the certificates required to enable HTTPS. HTTPS adoption on the Web took off at an unprecedented rate from the day Let’s Encrypt launched to the public.

One of the reasons Let’s Encrypt is so easy to use is that our community has done great work making client software that works well for a wide variety of platforms. We’d like to thank everyone involved in the development of over 60 client software options for Let’s Encrypt. We’re particularly excited that support for the ACME protocol and Let’s Encrypt is being added to the Apache httpd server.

Other organizations and communities are also doing great work to promote HTTPS adoption, and thus stimulate demand for our services. For example, browsers are starting to make their users more aware of the risks associated with unencrypted HTTP (e.g. Firefox, Chrome). Many hosting providers and CDNs are making it easier than ever for all of their customers to use HTTPS. Government agencies are waking up to the need for stronger security to protect constituents. The media community is working to Secure the News.

New Features

We’ve got some exciting features planned for 2018.

First, we’re planning to introduce an ACME v2 protocol API endpoint and support for wildcard certificates along with it. Wildcard certificates will be free and available globally just like our other certificates. We are planning to have a public test API endpoint up by January 4, and we’ve set a date for the full launch: Tuesday, February 27.

Later in 2018 we plan to introduce ECDSA root and intermediate certificates. ECDSA is generally considered to be the future of digital signature algorithms on the Web due to the fact that it is more efficient than RSA. Let’s Encrypt will currently sign ECDSA keys from subscribers, but we sign with the RSA key from one of our intermediate certificates. Once we have an ECDSA root and intermediates, our subscribers will be able to deploy certificate chains which are entirely ECDSA.

Infrastructure

Our CA infrastructure is capable of issuing millions of certificates per day with multiple redundancy for stability and a wide variety of security safeguards, both physical and logical. Our infrastructure also generates and signs nearly 20 million OCSP responses daily, and serves those responses nearly 2 billion times per day. We expect issuance and OCSP numbers to double in 2018.

Our physical CA infrastructure currently occupies approximately 70 units of rack space, split between two datacenters, consisting primarily of compute servers, storage, HSMs, switches, and firewalls.

When we issue more certificates it puts the most stress on storage for our databases. We regularly invest in more and faster storage for our database servers, and that will continue in 2018.

We’ll need to add a few additional compute servers in 2018, and we’ll also start aging out hardware in 2018 for the first time since we launched. We’ll age out about ten 2u compute servers and replace them with new 1u servers, which will save space and be more energy efficient while providing better reliability and performance.

We’ll also add another infrastructure operations staff member, bringing that team to a total of six people. This is necessary in order to make sure we can keep up with demand while maintaining a high standard for security and compliance. Infrastructure operations staff are systems administrators responsible for building and maintaining all physical and logical CA infrastructure. The team also manages a 24/7/365 on-call schedule and they are primary participants in both security and compliance audits.

Finances

We pride ourselves on being an efficient organization. In 2018 Let’s Encrypt will secure a large portion of the Web with a budget of only $3.0M. For an overall increase in our budget of only 13%, we will be able to issue and service twice as many certificates as we did in 2017. We believe this represents an incredible value and that contributing to Let’s Encrypt is one of the most effective ways to help create a more secure and privacy-respecting Web.

Our 2018 fundraising efforts are off to a strong start with Platinum sponsorships from Mozilla, Akamai, OVH, Cisco, Google Chrome and the Electronic Frontier Foundation. The Ford Foundation has renewed their grant to Let’s Encrypt as well. We are seeking additional sponsorship and grant assistance to meet our full needs for 2018.

We had originally budgeted $2.91M for 2017 but we’ll likely come in under budget for the year at around $2.65M. The difference between our 2017 expenses of $2.65M and the 2018 budget of $3.0M consists primarily of the additional infrastructure operations costs previously mentioned.

Support Let’s Encrypt

We depend on contributions from our community of users and supporters in order to provide our services. If your company or organization would like to sponsor Let’s Encrypt please email us at [email protected]. We ask that you make an individual contribution if it is within your means.

We’re grateful for the industry and community support that we receive, and we look forward to continuing to create a more secure and privacy-respecting Web!

Аз да не съм луд?…

Post Syndicated from Григор original http://www.gatchev.info/blog/?p=2102

– Няма никакво глобално затопляне! То е измишльотина на билдербергите! – заяви категорично продавачът, докато ми подаваше захранванията. – Това, че океаните се покачват, е дело на Бог! Той се е разсърдил на грешниците и предизвиква втория Потоп! Само че бавно, за да могат праведните и вярващи хора да имат време да се спасят!

Лекичко примигах. Твърдят, че на всеки автор му се случва рано или късно да срещне герои от произведенията си. Е, този път май беше мой ред. Да ви кажа честно, стряскащо си е. Добре, че списъкът за пазаруване беше дълъг, та се наложи да се съвзема бързо.

– Ще ми трябват и осем SATA кабела.

– И заради още нещо Потопът се бави. Рептилите! Нали са дяволски изчадия, пречат на Бога във всичко. И по принцип, и защото искат да завладеят света. Пък за какво им е наводнен свят?

– Сигурно защото са земноводни? – сътворих аз малко научно-фантастична таксономия.

– И отдавна да са го завладели, ама понеже се конкурират с илюминатите, си пречат едни на други – продължи събеседникът ми. – Билдербергите се опитват да посредничат между тях, ама не им се удава, Светият дух не е съгласен и проваля усилията им от небето…

– Мдааа… Кабелчетата наистина бяха осем. – И какво още за рептилите? – Беше започнало да ми става интересно.

– Те са, гадовете, дето са измислили ГМО-то! Затова то е едно такова, рептилско! Като го видиш, моментално ще го познаеш! Преструва се и на жито, и на леща, и на картофи, ама само изглежда като тях, отвътре е ГМО! И който го яде, също става ГМО отвътре. Така рептилите превземат хората масово. Унищожават душата, която Бог е вложил в нас, като ни е сътворявал!

– Ъъъъ… нямаше ли някаква теория, че хората са произлезли от маймуните? – Вече бях забелязал, че устата на събеседника ми спокойно работи паралелно с ръцете, без да им пречи. Нищо чудно родителите му да бяха попрекалявали с телешкото.

– Няма такова нещо! Маймуните са ги създали илюминатите. Направили са ги от хора, като биологичен експеримент. Били са несъгласни накъде точно ще водят експеримента, затова има различни видове маймуни. Изобщо цялата тая лъжа с еволюцията са я измислили пак илюминатите. Дарвин ли беше? Та, той тайно е бил виден илюминат. Това дето бил ходил на Папагалските острови да си напише теорията, е лъжа. Тайно е бил в Италия, в римските катакомби, нали илюминатите се крият там. И те там са го посветили и са му възложили какво да напише. Такава е всъщност историята!

Разклонителите също бяха под бройка, пач кабелите – и те.

– Та, той Нострадамус го е предсказал всичко това още на времето. Че когато планетата Нибиру се сблъска със Земята, Бог ще се разгневи на грешниците и ще изпрати втори Потоп! Ама понеже илюминатите са го преследвали, той си е пишел нещата много завоалирано. Затова толкова често ги тълкуват погрешно. Добре че е била Блаватска, да ги разгадае с Божията помощ. Тя е страшно силен медиум, и досега ни помага от Рая.

Мислено благодарих на Бога, че не съм вярващ, без да се замислям над логиката. Просто не исках да си представям как ли би реагирал вярващ християнин на идеята за Блаватска, която получава Божията помощ, отива в Рая и помага на човечеството оттам.

– Той, Нострадамус, не е ли също рептил? – подметнах наслуки.

– Истинският не е! По-късно рептилите са успели да го уловят и подменят, ама вече предсказанията му са били стигнали по целия свят. Затова рептилът се е опитал да го очерни, като направи фалшиви предсказания. Само че Господ не е позволил това да се случи, и останалите до днес предсказания са само истинските. Просто трябва много просветен ум, за да ги разбере.

Двата суича се сетих да си прибера, но за другото умът ми очевидно не беше достатъчно просветен. За да не се издам, подметнах:

– Ами планетата Нибиру, нали се сблъскахме с нея? Или не сме?

– Сблъскахме се, но само в астрален план! Бог не позволи да има физически сблъсък и я измести в друга астрална сфера, затова астрономите не можаха да я видят. Астралният сблъсък отслаби билдербергите, те нали се занимават с астрални работи. Затова и изпуснаха властта в Щатите и хората успяха да изберат Тръмп! Ама билдербергите пак ще го смъкнат, даже Русия няма да може да го опази! И това го е предрекъл Нострадамус!…

През следващите десетина минути ми се наложи да броя и разсортирам кошмарно количество и разнообразие от преходничета, кабелчета, куплунгчета – добре, че беше списъкът. За съжаление обаче пропуснах обширно обяснение за връзката на Дева Мария с индийските йоги. Запомних, че като малка е била обучавана в Шамбала, но останалото ми се изгуби.

– А нещо знаеш ли за как ни лъжат, че Земята е кръгла? Нали казват, че всъщност е плоска? – подкачих го, докато му подавах парите. Наум отбелязах, че бях сгрешил в преценката в началото. Чак такъв герой нямам.

Той се сепна и ме изгледа възмутено:

– Това са пълни глупости! Всяко дете знае, че земята е кръгла! Как мога да ги вярвам подобни измишльотини, че била плоска! Аз да не съм луд?

Изхарчени са милиарди за електронно управление?

Post Syndicated from Bozho original https://blog.bozho.net/blog/2999

Излязоха данни на БСК за разходите за електронно управление, сравнени с Естония. Изхарчени са милиарди от 2001-ва до 2016-та.

Като цяло данните най-вероятно са верни.

Е, Естония не е похарчила само 50 милиона. Всъщност, притеснително е, че БСК не е проверила тези данни и няма източник (Евростат дава разбивка по функции, но там няма е-управление/информационните технологии). Ето един очевиден източник през Google: https://www.nytimes.com/2014/10/09/business/international/estonians-embrace-life-in-a-digital-world.html (Естония харчи 60 милиона годишно за информационните технологии).

Но да оставим настрана тази грешка – тя прави нещата по-бомбастични, но не прави останалите наблюдения неверни. Всъщност, в доклада, с който внесохме пакета от реформи през 2015-та, имаше почти същите числа. И тогава, след заседание на парламентарната комисия по транспорт, излязоха новини колко много е похарчено. И пак бяхме недоволни за половин ден, и пак ги забравихме.

Всъщност е доста трудно да се измерят парите за „електронно управление“ – централен регистър за проекти и дейности за електронно управление нямаше допреди последните изменения на закона – оценките са „на око“ и никога не са пълни.

Но важни са причините – похарченото няма да се върне.

До 2016-та нямаше ясни правила и ясна посока за електронно управление, и най-вече – орган, който да преследва, стъпка по стъпка, политиката за е-управление. Да, има стратегии отдавна, има дори закон отдавна, но това всичко са пожелания. Докато не обвържеш разходите на министерствата и агенциите с контрол по същество и оценка на постигнатите резултати, те ще си харчат колкото им дойде за каквото им дойде. И в редките случаи, когато имат доброто желание нещо да направят, няма да имат експертизата да го направят.

Другата фундаментална разлика е електронната идентификация. БСК правилно посочват, че естонците имат електронна лична карта от 2001-ва. Според естонският президент това е ключов фактор и без него нищо не става. Затова и прокарахме законови изменения, за да имаме и ние електронна лична карта, макар и 17 години по-късно. През август правителството обаче ги отложи с още една година.

Държавна агенция „Електронно управление“, макар и с малък капацитет, успява да бута нещата напред. По-бавно, отколкото ни се иска, и не с темпове, с които да настигнем Естония, но и БСК отбелязва напредъка по някои направления (подкарването на системата за електронно връчване, например). За съжаление все още не е влязла в пълните си правомощия, които сме предвидили в закона и все още е неефективна по немалко направления – „държавен облак“, например, още няма. Няма и електрона идентификация, която да даде необходимата масовост на използване. Писал съм за всички тези неща многократно (обобщени тук), но нещата в крайна сметка опират до два фактора. И те не са колко пари са изхарчени.

Политическа воля и експертен потенциал. Ако няма минимум вицепремиер, който да натиска постоянно за случването на електронното управление, то няма да се случи. Но простото желание също не е достатъчно, защото администрацията, министрите, опитните „играчи“ имат добри оправдания защо нещо не може да стане или защо не трябва да стане. Затова трябва експертния потенциал на високо ниво, който да отсее оправданията от реалните проблеми и да ги реши почти собственоръчно, с помощта на „белите лястовици“ в администрацията (има такива).

Иначе ще продължава да има стратегии, ще продължаваме през две години да отчитаме колко милиарда са изхарчени, ще въздъхваме, като чуем Естония. А там се е получило много „лесно“. Просто е имало политически консенсус, че страната ще става дигитална и достатъчно добронамерени експерти, които да вземат правилните технологични решения. И Естония не е започнала от 2001-ва година дигитализацията – започнала е много по-рано, в училищата, с изграждане на дигиталната култура у гражданите. Далновидно. В годините, в които у нас са се гонили мутри, а БСП е фалирало държавата. 20 години по-късно ние отлагаме електронните лични карти още веднъж и говорим основно за инфраструктурни проекти.

А парите за електронно управление си изтичат, нерядко към „наши фирми“, нерядко много повече, отколкото предполага обхвата на проекта.

Просто начин на мислене. Който не се санкционира на избори, така че продължава да се възпроизвежда.

ЕСПЧ: Видеокамери и видеозаписи в лекционни зали нарушават правото на личен живот на преподавателите

Post Syndicated from nellyo original https://nellyo.wordpress.com/2017/12/03/echr-art8-21/

 На 28 ноември 2017 г. ЕСПЧ оповести решението си по делото  Antović и Mirković v. Черна гора ( № 70838/13). С  четири гласа за  и три особени мнения Съдът реши, че има  нарушение на член 8 ЕКПЧ (право на зачитане на личния и семейния живот), като присъди съответно обезщетение.

Двама професори в университета на Черна гора, Невенка Антович и Йован Миркович, са жалбоподатели  по делото.  В университета са монтирали видеокамери.  Професорите са обжалвали решението, но националните съдилища приемат, че аудиториите, в които  Антович и Миркович  преподават, са публични пространства и няма неправомерна намеса в личния живот на преподавателите.

Съдът в Страсбург отхвърля доводите на правителството, че делото е недопустимо, тъй като аудиторията е публично пространство. Съдът преди всичко намира, че  – както вече е установил в други дела – личният живот може да включва професионални дейности. Следователно член 8 ЕКПЧ е приложим:

43.  Съдът  провери дали жалбоподателите имат оправдано очакване за неприкосновеност  на личния живот. […]

44. Що се отнася до настоящия случай, Съдът отбелязва, че университетските аудитории са работните места на преподавателите. Тайно видеонаблюдение на   работното място трябва да се разглежда като  значителна намеса в личния живот […] Това води до   възпроизводима документация  за поведението на човека в неговото работно място [...] Няма причина Съдът да се отклони от тази констатация, дори ако се отнася до случаите на явно видеонаблюдение на служител на  работното място […]   Правото на личен живот съществува, дори и да е ограничено, доколкото е необходимо (вж. Bărbulescu, § 80).

По същество:

59. според националния закон оборудването за видеонаблюдение  може да се инсталира в официални или търговски помещения, но само ако целите –  по-специално безопасността на хора или имущество или за защита на поверителни данни –  не могат да бъдат постигнати в по друг начин. Съдът отбелязва, че в настоящия случай е въведено видеонаблюдение, за да се гарантира безопасността на имуществото и хората, включително студентите, и за наблюдение на преподаването. Една от тези цели, а именно надзорът върху преподаването, изобщо не е предвидена от закона като основание за видеонаблюдение. Освен това  изрично е постановено, че няма доказателства, че  имущество или хората са били в опасност […]. От своя страна   правителството не предоставя никакво доказателство за противното в това отношение, нито пък показва, че  преди това е разглеждало други мерки като алтернатива.

Професорите смятат също, че  нямат ефективен контрол над събраната информация, поради което наблюдението е незаконно.

ЕСПЧ потвърди : наблюдението е неправомерна намеса в правото на личен живот, нарушение на чл.8 ЕКПЧ.

 В едното особено мнение се приема, че преподаването не е част от личния живот:

За  мнозинството е достатъчно, че  видеонаблюдението или мониторингът се провежда на  работното място – залата, където  професорите преподават и общуват   със студенти. Според нас това е много широко  разбиране на понятието “личен живот”.

В другите две особени мнения се приема, че чл. 8 е приложим и има нарушение, но с различна аргументация:

Настоящият случай не се отнася до камери за сигурност, поставени например на входовете и изходите на университетските сгради. Тя се отнася до видео наблюдението на аудиториите. Гарантиране на  безопасността на хората и имуществото  е  една от целите на мярката , другата цел е мониторингът на учебните дейности  –  фактът, че деканът е имал достъп до записите, изглежда потвърждава, че това наистина е преследвана цел.
Университетските аудитории не са нито частно, нито обществено място. Те са места, където преподавателите срещат своите студенти и взаимодействат с тях.  Струва ни се, че в такова взаимодействие преподавателят може да има очаквания за неприкосновеност на личния живот –  в смисъл, че   обикновено се очаква, че това, което се случва в класната стая,  може да се наблюдава само от тези, които са оправомощени да присъстват в клас  и действително   присъстват.  […]

Filed under: Media Law, Uncategorized Tagged: еспч, чл.8

Мария Габриел в София: #AVMSD

Post Syndicated from nellyo original https://nellyo.wordpress.com/2017/12/02/avmsd-16/

Мария Габриел, член на Европейската комисия с ресор Цифрова икономика и цифрово общество, участва в кръгла маса на тема: “Предизвикателства пред медийния сектор в Европа“,  организирана от Представителството на Европейската комисия в България и Съветът за електронни медии. Бяха представени две теми:

  • актуалните въпроси по Директивата за аудиовизуалните медийни услуги и 
  • обявената обществена консултация по въпросите на фалшивите новини и дезинформацията.

I

Първата тема – ход на ревизията на Директивата за аудиовизуални медийни услуги.

Първоначалният проект и развитията по 2016/0151(COD) могат да се следят тук.

Според Стратегическата 18-месечна програма на Съвета (председателство Естония, България, Австрия) трите председателства ще приключат работата по ключови инициативи, свързани с цифровия единен пазар, включително

улесняване на свързаността и постигане на напредък в развитието на конкурентоспособен и справедлив цифров единен пазар чрез насърчаване на трансграничната електронна търговия (онлайн продажба на стоки, предоставяне на цифрово съдържание, реформа на авторското право, аудиовизуални медийни услуги, доставяне на колетни пратки) и чрез преход към интелигентна икономика (свободно движение на данни, преглед на регулаторната рамка в областта на далекосъобщенията, инициативи в областта на дружественото право) и укрепване на доверието и сигурността в сферата на цифровите услуги (нов пакет за защита на данните)

Работата по  медийната директива (впрочем и по директивата за авторското право) продължават по време на Българското председателство – в този дух е съобщението на посланика на Естония в ЕС:

https://platform.twitter.com/widgets.js

 

От изложението на г-жа Габриел стана ясно, че е тази седмица е проведен  пети триалог, в който тя участва лично. Работата продължава (“финализиране се очаква”) по време на Българското председателство. Като открити бяха посочени три тематични области:

(1) разширяване на обхвата на директивата, включване на стрийминга в услугите,  нови адресати – социалните медии и платформите за видеосподеляне;

(2) квотата на произведенията, създадени от европейски продуценти – и празмерът на квотата (предложения: 20 на сто –  ЕК, 30 на сто –  ЕП), и дефинициите са дискусионни;

(3) търговските съобщения – и правилата (почасова продължителност и продължителност за денонощие), и разполагането (предложение: двоен лимит за светло и тъмно време), и прекъсването (предложение: 20-минутно правило) са още предмет на обсъждане.

По повод откритите въпроси:

  • Директивата разширява обхвата си с всяка ревизия. Все пак, когато се обсъжда отговорност на платформите, да бъде в контекста на Директивата за електронната търговия – защото има риск да се стигне  до мълчаливо преуреждане или отмяна на нейните принципи.  В допълнение практиката на ЕСПЧ (решението Делфи за отговорността за съобщения във форумите) илюстрира проблемите, възникващи при нееднозначно разбиране на отговорността в правото на ЕС и в международното право.  По подобни съображения е важна обсъжданата Директива за авторското право, в частност чл.13 – който (споделям позицията на EDRI) трябва да бъде заличен, а нови права не следва да бъдат създавани (чл.11 проекта).
  • Квотата на европейските произведения съществува реално на по-високи нива от предвиденото в директивата. В тази област проблем  е отношението европейска – национална  квота, защото местните индустрии  настояват именно за национална квота – а това би било мярка със съвсем различни цели от   европейската квота (единен пазар).
  • Уредбата на електронните търговски съобщения се либерализира (в България  – и дерегулира) непрекъснато. Все някъде е добре този процес да спре, за да не се превърне телевизията в поредица търговски съобщения, прекъсвани с основно съдържание. Слушаме уверенията на доставчиците, че потребителите  са най-голямата им ценност и телевизиите не биха програмирали против интересите на зрителите, но все пак нека останат и правни гаранции срещу океаните от търговски съобщения.

Ключови за регулацията остават балансите:

  • индустрии / аудитории – както обикновено, натискът на индустриите е мощен и организиран, докато аудиториите са слабо организирани и слабо представени в диалога – дано ЕП  защити интересите на гражданите;
  • гъвкавост / недопускане на фрагментиране – съвсем точно наблюдение: неслучайно при предната ревизия ЕК обърна внимание, че гъвкавост и свобода е добре, но не и свобода при  дефинициите – защото различните дефиниции в националните мерки компрометират ефективното прилагане;
  • регулиране / саморегулиране – никой не е против саморегулирането, но самата ЕК преди време беше заявила, че има области като интелектуалната собственост и конкурентното право, които не могат по естеството си да бъдат оставени само на саморегулиране.

II

По втората тема – фалшивите новини –   г-жа Габриел поясни, че ЕК работи по следната логика:  дефиниция – обзор на добри практики – мерки, като на този етап не се мисли за законодателство. Още за тази част от срещата –  в медиите.

През 2018 г. се очаква:

  • създаване на работна група на високо равнище и доклад в тримесечен срок;
  • Евробарометър по въпроси, свързани с фалшивите новини;
  • Съобщение на ЕК към средата на 2018 г.

Съвсем наскоро (9 ноември 2017 ) Асоциацията на европейските журналисти проведе международна конференция с последващо обучение по въпросите на дезинформацията и фалшивите новини. Имах възможност да участвам (вж последната част от  записа на конференцията):

  • Смятам, че трябва да се започне с  дефиниране, но на следващо място да се продължи с категоризиране на фалшивите новини.
  • Реакцията към различните категории фалшиви новини  трябва да е различна. Правото вече предвижда санкции за някои категории лъжа – напр. клеветата или подвеждащата реклама. Не съм   сигурна, че правото няма да се намеси с нови мерки в най-сериозните случаи, когато става дума за дезинформационни кампании, които могат да заплашат националната сигурност.
  • Няма единно мнение по въпроса кой идентифицира фалшивите новини или – с други думи: кой владее истината.  Италия предлага това да са нов тип конкурентни регулатори (аналогия с регулирането на подвеждащата реклама), Чехия – звено в МВР (при риск за националната сигурност). ЕК казва, че няма нужда от Министерство на истината – но по-добре ли е това да е частна компания? Виждали сме как Facebook различава морално/неморално – предстои ли да се заеме и с преценката вярно/невярно?  Не всички са съгласни. Но точно това се случва, неслучайно се обсъжда – научаваме – контранотификация срещу свръхпремахване на съдържание.

 

Filed under: EU Law, Media Law Tagged: давму, fake

Our brand-new Christmas resources

Post Syndicated from Laura Sach original https://www.raspberrypi.org/blog/christmas-resources-2017/

It’s never too early for Christmas-themed resources — especially when you want to make the most of them in your school, Code Club or CoderDojo! So here’s the ever-wonderful Laura Sach with an introduction of our newest festive projects.

A cartoon of people singing Christmas carols - Raspberry Pi Christmas Resources

In the immortal words of Noddy Holder: “it’s Christmaaaaaaasssss!” Well, maybe it isn’t quite Christmas yet, but since the shops have been playing Mariah Carey on a loop since the last pumpkin lantern hit the bargain bin, you’re hopefully well prepared.

To get you in the mood with some festive fun, we’ve put together a selection of seasonal free resources for you. Each project has a difficulty level in line with our Digital Making Curriculum, so you can check which might suit you best. Why not try them out at your local Raspberry Jam, CoderDojo, or Code Club, at school, or even on a cold day at home with a big mug of hot chocolate?

Jazzy jumpers

A cartoon of someone remembering pairs of jumper designs - Raspberry Pi Christmas Resources

Jazzy jumpers (Creator level): as a child in the eighties, you’d always get an embarrassing and probably badly sized jazzy jumper at Christmas from some distant relative. Thank goodness the trend has gone hipster and dreadful jumpers are now cool!

This resource shows you how to build a memory game in Scratch where you must remember the colour and picture of a jazzy jumper before recreating it. How many jumpers can you successfully recall in a row?

Sense HAT advent calendar

A cartoon Sense HAT lit up in the design of a Christmas pudding - Raspberry Pi Christmas Resources

Sense HAT advent calendar (Builder level): put the lovely lights on your Sense HAT to festive use by creating an advent calendar you can open day by day. However, there’s strictly no cheating with this calendar — we teach you how to use Python to detect the current date and prevent would-be premature peekers!

Press the Enter key to open today’s door:

(Note: no chocolate will be dispensed from your Raspberry Pi. Sorry about that.)

Code a carol

A cartoon of people singing Christmas carols - Raspberry Pi Christmas Resources

Code a carol (Developer level): Have you ever noticed how much repetition there is in carols and other songs? This resource teaches you how to break down the Twelve days of Christmas tune into its component parts and code it up in Sonic Pi the lazy way: get the computer to do all the repetition for you!

No musical knowledge required — just follow our lead, and you’ll have yourself a rocking doorbell tune in no time!

Naughty and nice

A cartoon of Santa judging people by their tweets - Raspberry Pi Christmas Resources

Naughty and nice (Maker level): Have you been naughty or nice? Find out by using sentiment analysis on your tweets to see what sort of things you’ve been talking about throughout the year. For added fun, why not use your program on the Twitter account of your sibling/spouse/arch nemesis and report their level of naughtiness to Santa with an @ mention?

raspberry_pi is 65.5 percent NICE, with an accuracy of 0.9046692607003891

It’s Christmaaaaaasssss

With the festive season just around the corner, it’s time to get started on your Christmas projects! Whether you’re planning to run your Christmas lights via a phone app, install a home assistant inside an Elf on a Shelf, or work through our Christmas resources, we would like to see what you make. So do share your festive builds with us on social media, or by posting links in the comments.

The post Our brand-new Christmas resources appeared first on Raspberry Pi.

Sky’s Pirate Site-Blocking Move is Something For North Korea, ISPs Say

Post Syndicated from Andy original https://torrentfreak.com/skys-pirate-site-blocking-move-is-something-for-north-korea-isps-say-171129/

Entertainment companies have been taking legal action to have pirate sites blocked for more than a decade so it was only a matter of time before New Zealand had a taste of the action.

It’s now been revealed that Sky Network Television, the country’s biggest pay-TV service, filed a complaint with the High Court in September, demanding that four local Internet service providers block subscriber access to several ‘pirate’ sites.

At this point, the sites haven’t been named, but it seems almost inevitable that the likes of The Pirate Bay will be present. The ISPs are known, however. Spark, Vodafone, Vocus and Two Degrees control around 90% of the Kiwi market so any injunction handed down will affect almost the entire country.

In its application, Sky states that pirate sites make available unauthorized copies of its entertainment works, something which not only infringes its copyrights but also undermines its business model. But while this is standard fare in such complaints, the Internet industry backlash today is something out of the ordinary.

ISPs in other jurisdictions have fought back against blocking efforts but few have deployed the kind of language being heard in New Zealand this morning.

Vocus Group – which runs the Orcon, Slingshot and Flip brands – is labeling Sky’s efforts as “gross censorship and a breach of net neutrality”, adding that they’re in direct opposition to the idea of a free and open Internet.

“SKY’s call that sites be blacklisted on their say so is dinosaur behavior, something you would expect in North Korea, not in New Zealand. It isn’t our job to police the Internet and it sure as hell isn’t SKY’s either, all sites should be equal and open,” says Vocus Consumer General Manager Taryn Hamilton.

But in response, Sky said Vocus “has got it wrong”, highlighting that site-blocking is now common practice in places such as Australia and the UK.

“Pirate sites like Pirate Bay make no contribution to the development of content, but rather just steal it. Over 40 countries around the world have put in place laws to block such sites, and we’re just looking to do the same,” the company said.

The broadcaster says it will only go to court to have dedicated pirate sites blocked, ones that “pay nothing to the creators” while stealing content for their own gain.

“We’re doing this because illegal streaming and content piracy is a major threat to the entertainment, creative and sporting industries in New Zealand and abroad. With piracy, not only is the sport and entertainment content that we love at risk, but so are the livelihoods of the thousands of people employed by these industries,” the company said.

“Illegally sharing or viewing content impacts a vast number of people and jobs including athletes, actors, artists, production crew, customer service representatives, event planners, caterers and many, many more.”

ISP Spark, which is also being targeted by Sky, was less visibly outraged than some of its competitors. However, the company still feels that controlling what people can see on the Internet is a slippery slope.

“We have some sympathy for this given we invest tens of millions of dollars into content ourselves through Lightbox. However, we don’t think it should be the role of ISPs to become the ‘police of the internet’ on behalf of other parties,” a Spark spokesperson said.

Perhaps unsurprisingly, Sky’s blocking efforts haven’t been well received by InternetNZ, the non-profit organization which protects and promotes Internet use in New Zealand.

Describing the company’s application for an injunction as an “extreme step”, InternetNZ Chief Executive Jordan Carter said that site-blocking works against the “very nature” of the Internet and is a measure that’s unlikely to achieve its goals.

“Site blocking is very easily evaded by people with the right skills or tools. Those who are deliberate pirates will be able to get around site blocking without difficulty,” Carter said.

“If blocking is ordered, it risks driving content piracy further underground, with the help of easily-deployed and common Internet tools. This could well end up making the issues that Sky are facing even harder to police in the future.”

What most of the ISPs and InternetNZ are also agreed on is the need to fight piracy with competitive, attractive legal offerings. Vocus says that local interest in The Pirate Bay has halved since Netflix launched in New Zealand, with traffic to the torrent site sitting at just 23% of its peak 2013 levels.

“The success of Netflix, iTunes and Spotify proves that people are willing to pay to access good-quality content. It’s pretty clear that SKY doesn’t understand the internet, and is trying a Hail Mary to turnaround its sunset business,” Vocus Consumer General Manager Taryn Hamilton said.

The big question now is whether the High Court has the ability to order these kinds of blocks. InternetNZ has its doubts, noting that it should only happen following a parliamentary mandate.

Source: TF, for the latest info on copyright, file-sharing, torrent sites and more. We also have VPN discounts, offers and coupons

Amazon EC2 Update – Streamlined Access to Spot Capacity, Smooth Price Changes, Instance Hibernation

Post Syndicated from Jeff Barr original https://aws.amazon.com/blogs/aws/amazon-ec2-update-streamlined-access-to-spot-capacity-smooth-price-changes-instance-hibernation/

EC2 Spot Instances give you access to spare compute capacity in the AWS Cloud. Our customers use fleets of Spot Instances to power their CI/CD environments & traffic generators, host web servers & microservices, render movies, and to run many types of analytics jobs, all at prices that offer significant savings in comparison to On-Demand Instances.

New Streamlined Access
Today we are introducing a new, streamlined access model for Spot Instances. You simply indicate your desire to use Spot capacity when you launch an instance via the RunInstances function, the run-instances command, or the AWS Management Console to submit a request that will be fulfilled as long as the capacity is available. With no extra effort on your part you’ll save up to 90% off of the On-Demand price for the instance type, allowing you to boost your overall application throughput by up to 10x for the same budget. The instances that you launch in this way will continue to run until you terminate them or if EC2 needs to reclaim them for On-Demand usage. At that point the instance will be given the usual 2-minute warning and then reclaimed, making this a great fit for applications that are fault-tolerant.

Unlike the old model which required an understanding of Spot markets, bidding, and calls to a standalone asynchronous API, the new model is synchronous and as easy to use as On-Demand. Your code or your script receives an Instance ID immediately and need not check back to see if the request has been processed and accepted.

We’ve made this as clean and as simple as possible, with the expectation that it will be easy to modify many current scripts and applications to request and make use of Spot capacity. If you want to exercise additional control over your Spot instance budget, you have the option to specify a maximum price when you make a request for capacity. If you use Spot capacity to power your Amazon EMR, Amazon ECS, or AWS Batch clusters, or if you launch Spot instances by way of a AWS CloudFormation template or Auto Scaling Group, you will benefit from this new model without having to make any changes.

Applications that are built around RequestSpotInstances or RequestSpotFleet will continue to work just fine with no changes. However, you now have the option to make requests that do not include the SpotPrice parameter.

Smooth Price Changes
As part of today’s launch we are also changing the way that Spot prices change, moving to a model where prices adjust more gradually, based on longer-term trends in supply and demand. As I mentioned earlier, you will continue to save an average of 70-90% off the On-Demand price, and you will continue to pay the Spot price that’s in effect for the time period your instances are running. Applications built around our Spot Fleet feature will continue to automatically diversify placement of their Spot Instances across the most cost-effective pools based on the configuration you specified when you created the fleet.

Spot in Action
To launch a Spot Instance from the command line; simply specify the Spot market:

$ aws ec2 run-instances –-market Spot --image-id ami-1a2b3c4d --count 1 --instance-type c3.large 

Instance Hibernation
If you run workloads that keep a lot of state in memory, you will love this new feature!

You can arrange for instances to save their in-memory state when they are reclaimed, allowing the instances and the applications on them to pick up where they left off when capacity is once again available, just like closing and then opening your laptop. This feature works on C3, C4, and certain sizes of R3, R4, and M4 instances running Amazon Linux, Ubuntu, or Windows Server, and is supported by the EC2 Hibernation Agent.

The in-memory state is written to the root EBS volume of the instance using space that is set-aside when the instance launches. The private IP address and any Elastic IP Addresses are also preserved across a stop/start cycle.

Jeff;

КЗЛД: Десет практически стъпки за прилагане на новия Регламент относно защитата на данните (GDPR)

Post Syndicated from nellyo original https://nellyo.wordpress.com/2017/11/28/gdpr/

На 25 май 2018 г. влиза в сила новият Общ регламент относно защитата на   данните –  Регламент (ЕС) 2016/679 на Европейския парламент и на Съвета от 27 април 2016 година относно защитата на физическите лица във връзка с обработването на лични данни и относно свободното движение на такива данни и за отмяна на Директива 95/46/EО 

Комисията за защита на личните данни е издала указания – десет практически стъпки за прилагане на новия Общ регламент.

 

 

Filed under: Digital, EU Law, Media Law Tagged: gdpr

Новото законодателство за изпиране на пари: разкриване на действителните собственици

Post Syndicated from nellyo original https://nellyo.wordpress.com/2017/11/28/ownership-2/

Разкриването на действителните собственици в медийния сектор у нас е нерешен въпрос в годините на прехода. Предвидени мерки има, водят се и регистри:  от МК  – на действителните собственици на печатни издания и от СЕМ – на доставчиците на радио и телевизия. Но мерките не водят до задоволителен резултат.

В допълнение: не само  собствеността,  но и механизмите за влияние върху решенията следва да се идентифицират и да бъдат прозрачни –

като   необезпечените кредити от КТБ за 24 часа и Труд  и

като  фигурата на консултантите – Красимир Гергов, Ирена Кръстева и пр. –  т.нар. консултант може да се окаже собственик с права на контрол върху важни решения (вж напр.  т.4.4 в този договор).

 

Ето защо   установяването на действителните собственици и изясняването на произхода на средствата, предвидени в приетия на първо четене законопроект за мерките против изпиране на пари – въвеждащ съответната директива на ЕС – имат връзка с евентуалната прозрачност на собствеността и влиянията в медийния сектор.

Дали това е добър инструмент – да не се забравя, става дума за много сериозно навлизане в личната сфера, така че трябва да бъдат осигурени пропорционалност и баланс –  и дали в България е възможно властта да приема мерки, които ефективно могат да се насочват и срещу нейни представители и спонсори – остава да видим.

*

702-01-14 законопроект с мотиви

Из мотивите към законопроекта:

В раздели V и VІ са регламентирани съответно условията и редът за идентифициране на клиенти и проверка на тяхната идентификация, както и идентифицирането на действителните собственици и проверка на тяхната идентификация.

Отчетена е необходимостта от точна и актуална информация за действителния собственик като ключов фактор при разкриването на престъпления с оглед на възможността самоличността на дадено лице да бъде скрита зад дружествена структура.

Сред основните промени в сега действащия режим по идентифициране на действителните собственици и проверка на тяхната идентификация е изричното формулиране на задължение за всички учредени на територията на Република България юридически лица и други правни образувания и лицата им за контакт, както и всички физически и юридически лица и други правни образувания, които действат на територията на Република България в качеството си на доверителни собственици на тръстове, попечителски фондове и други подобни чуждестранни правни образувания, учредени и съществуващи съобразно правото на юрисдикциите, допускащи такива форми на доверителна собственост, и лицата им за контакт да получават, да разполагат и да предоставят в определените в закон случаи подходяща, точна и актуална информация относно физическите лица, които са техни действителни собственици, включително с подробни данни относно притежаваните от тях права. Друго съществено задължение за тези лица и правни образувания е да предоставят на задължените по закона субекти при извършване на идентификация и нейната проверка информация относно действителните собственици. Предвидено е и задължение такава информацията да се предоставя при поискване и на дирекция „Финансово разузнаване” на Държавна агенция „Национална сигурност” и на компетентните органи по този закон в определения от тях срок.

Така формулираните задължения кореспондират с изискванията на чл. 30 и 31 от Директивата и на Препоръки 24 и 25 на FATF и имат за цел въвеждане на гаранции за възможността на задължените по закона субекти да извършват идентификация на действителните собственици и нейната проверка.

Изискването за наличието на лицe за контакт, което да отговаря за изпълнението на изискването за прозрачност на действителния собственик, съответства на международните стандарти (Тълкувателни бележки по Препоръка 24, буква „Б”, т. 9 на FATF).

В § 2 от Допълнителните разпоредби към законопроекта е формулирана подробна дефиниция на понятието „действителен собственик”, която съответства напълно на дефиницията в чл. 3 т. 6 от Директивата. С цел внасяне на яснота при тълкуването и улесняване прилагането на разпоредбите относно идентифицирането на действителните собственици и проверката на тяхната идентификация в дефиницията прекият и непрекият контрол са разграничени. Дефиницията не се прилага за публичните дружества, но в законопроекта е предвидено задължение за задължените по закона субекти по отношение на техни клиенти – юридически лица, чиито акции се търгуват на регулиран пазар, които се подчиняват на изискванията за оповестяване в съответствие с правото на Европейския съюз или на еквивалентни международни стандарти, осигуряващи адекватна степен на прозрачност по отношение на собствеността, да събират информация за дяловото участие, подлежаща на разкриване по реда на глава единадесета, раздел I от Закона за публичното предлагане на ценни книжа.

Предвидено е информацията и данните за действителните собственици да се вписват по партидите на учредените на територията на Република България юридически лица и други правни образувания в търговския регистър и в регистър БУЛСТАТ, а на физическите и юридическите лица и други правни образувания, които действат на територията на Република България в качеството си на доверителни собственици на тръстове, попечителски фондове и други подобни чуждестранни правни образувания, учредени и съществуващи съобразно правото на юрисдикциите, допускащи такива форми на доверителна собственост – в регистър БУЛСТАТ.

С цел транспониране на разпоредбите на чл. 30 и 31 от Директивата в Преходните и заключителните разпоредби на законопроекта са предвидени промени и в Търговския закон, Закона за юридическите лица с нестопанска цел, Закона за кооперациите, Закона за регистър БУЛСТАТ, Закона за икономическите и финансовите отношения с дружествата, регистрирани в юрисдикции с преференциален данъчен режим, контролираните от тях лица и техните действителни собственици и др. При регламентиране на реда и условията за идентификация и проверка на идентификацията на действителните собственици са взети предвид и препоръките, отправени към България от Глобалния форум за прозрачност и обмен на информация за данъчни цели към Организацията за икономическо сътрудничество и развитие (ОИСР).

В раздел VІІ са регламентирани редът и условията за изясняване на произхода на средствата.

Предвиждат се следните допустими способи за прилагане на тази мярка – събиране на информация от клиента за основната му дейност, включително за действителния и за очаквания обем на деловите взаимоотношения и на операциите или сделките, които се очаква да бъдат извършвани в рамките на тези взаимоотношения, чрез попълване на въпросник или по друг подходящ начин; събиране на друга информация от официални независими източници  – данни от публично достъпни регистри и бази от данни и др.; информация, събирана във връзка с изпълнението на изискванията на този или на други закони и подзаконови нормативни актове, включително Валутния закон, която да показва ясен произход на средствата; използване на информация, обменяна в рамките на групата, която да показва ясен произход на средствата, когато е приложимо; проследяване на паричните потоци в рамките на установените делови взаимоотношения с клиента, при което да е виден ясен произход на средствата, когато е приложимо.

Filed under: BG Law Making, BG Media, EU Law, Media Law

Добре отъпканите пътеки и тротоари на България

Post Syndicated from Боян Юруков original https://yurukov.net/blog/2017/heatmap-activnost/

Да се представят и осмислят големи масиви от информация е трудна задача. В бизнеса тя обаче става все по-важна, тъй като много фирми разбират важността на данните, които събират и ползата, която могат да имат от тях. Част от тези данни могат да бъдат пуснати свободно в полза на обществото, което както съм писал преди, е новата дефиниция на социална отговорност.

Данните обаче не трябва да са сухи, графиките скучни и затворени в нескопосани слайдове. Те може да са красиви, същинско изкуство. Всъщност, самият процес на създаване да доставя дори повече удоволствие от самия резултат. За мен лично такъв беше проектът за карта на българчетата родени в чужбина. В началото на ноември попаднах на нещо много по-добро, всеобхватно и красиво. Услугата за следене на спортна активност Strava са обновили картата си съдържаща един милард записани дейности – каране на колело, бягане, плуване – по цял свят. Резултатът е просто прекрасен.

Само хора, които са се занимавали с визуализация на гео данни биха оценили описанието как се е променила картата за последните две години. Сложността в изчистване на неточности в измерванията, изглаждане на линиите за сметка на точността, но в полза на четимостта, филтриране на данните и прочие подробности са твърде технически. Затова ще покажа само няколко отрязъка от картата, които може да са интересни на всички. Интерактивната версия ще намерите тук.

В началото виждате картата на София събираща цялата дейност. Забелязват се няколко доста „горещи“ региона – най-вече парковете. Следващата снимка показва само бягането и ходенето наложени върху сателитна снимка на града. Отново парковете са изключително посещавани. Почти нищо във Факултета, Красно село, Манастирски ливади и няколко други крайни квартала.

Тук не разглеждам активността плуване, макар да се забелязват няколко басейна в градовете – най-вече по гребната в Пловдив. Липсата на активност по езерата е ясно видима и показва колко нечисти са и колко липсва спортна инфраструктура.

Ако погледнем зимните спортове (ски, кънки), вижда се ясно очертана пистата на Витоша заедно с няколко връщания с колите до София.

Погледнато по на юг се вижда значително по-голяма активност на Боровец и Банско заедно с ясни очертания къде са пистите.

За цяла България карането на ски изглежда ето така. Това изглежда е практически единственият зимен спорт. Разбира се, важно е да се разбере, че това тук не е представителна извадка за всички спортуващи – нито каращите ски, нито колело, нито бягащите. Това показва активността единствено на потребителите на едно от много приложения за следене на спортна активност, макар и едно от големите. Явно достатъчно в България го използват, за да виждаме толкова добре очертанията.

Често Банско се сравнява с пистите в Алпите – какви цени и условия имало там и какви тук. Това се дава като аргумент ту за, ту против конкретния концесионер, нова писта или лифт. Тези карти дават ясна представа за разликата в мащабите и възможностите, които предоставя релефа. От там идва и конкуренцията, алтернативите и прочие.

Тук виждате по-голямата част от Алпите – предимно Швейцария и Австрийската част. Мащабът е еднакъв с горната карта.

Връщаме се в България, тъй като всъщност ските не са единствените зимни спортове записани от мобилното приложение. Ето тук виждате ледената пързалка в Пловдив.Такива се забелязват в София и други градове.

И накрая – пешеходната карта на България. Мисля, че всички дължим овации на онези записали активност „ходене“ по билото на Стара Планина от край до край.

Картата сама по себе си е интересна и красива, поне по мое мнение, но може да бъде полезна по още неочаквани начини. Strava очевидно са направили картата, за да покажат колко много потребители имат и да поставят в контекст активността на всеки от тях. Данните, които са пуснали са анонимизирани и взети заедно показват „горещите“ точки в градовете. Това може да е още един източник на информация за пропуски в инфраструктурата, неизползван потенциал, концентрация на пешеходци и велосипедисти, а от там и повишен риск от инциденти и прочие. Именно от там идва ползата частни компании да споделят „изчистени“ данни от работата си – допринасят към общата екосистема.

Отворено законодателство [лекция]

Post Syndicated from Bozho original https://blog.bozho.net/blog/2996

Преди година написах, че макар гражданите да са длъжни да знаят законите, държавата не им помага по никакъв начин за това – законите се публикуват само като изменения в държавен вестник (чиято електронна форма е PDF), а за нормален човек това не е четимо и полезно но никакъв начин. Това ни прави почти последни в Европа по достъпност на законодателството. Причините за това са много, свързани и с авторски права, и с неспособността на държавата да върши качествено И тази работа, но в крайна сметка гражданите ползваме lex.bg и се надяваме версията там да е актуална.

Това обаче е недостатъчно и поради това реших да направя лекция за „Отворено законодателство“ на OpenFest, на която да разкажа както за текущия законодателен процес и проблемите, свързани с него, така и да предложа технически решения. В рамките на лекцията предложих създаване на проект OpenLex, чрез който законодателството да стане по-достъпно.

Видео от лекцията може да видите тук:

А слайдовете са тук:

Три седмици след OpenFest, все още не съм намерил време да инициирам координационна среща по проекта с хората изявили желание, което е сериозен пропуск от моя страна, но ще се опитам да го коригирам скоро.

А ако проектът бъде реализиран, ще имаме не просто по-удобно и достъпно законодателство (каквото lex.bg до известна степен дава), но и реализирани компоненти и взети технически решения, чрез които държавата (в лицето или на Народното събрание, или на Министерския съвет) да поддържа законодателството в електронен, машинно-четим вид. А самият законодателен процес да не минава през разпечатване, сканиране и разпращане на doc файлове с 10 цвята в допълнение на track changes, а да бъде структуриран и да позволява съвместна работа на много участници. Това би предполагало технически грамотни депутати, разбира се. Ама и до там ще стигнем все някой ден.

Надявам се и лекцията ми да е полезна за всеки, който в даден бъдещ момент ще иска да оптимизира законодателния процес и достъпа до законодателство.

Using Amazon Redshift Spectrum, Amazon Athena, and AWS Glue with Node.js in Production

Post Syndicated from Rafi Ton original https://aws.amazon.com/blogs/big-data/using-amazon-redshift-spectrum-amazon-athena-and-aws-glue-with-node-js-in-production/

This is a guest post by Rafi Ton, founder and CEO of NUVIAD. NUVIAD is, in their own words, “a mobile marketing platform providing professional marketers, agencies and local businesses state of the art tools to promote their products and services through hyper targeting, big data analytics and advanced machine learning tools.”

At NUVIAD, we’ve been using Amazon Redshift as our main data warehouse solution for more than 3 years.

We store massive amounts of ad transaction data that our users and partners analyze to determine ad campaign strategies. When running real-time bidding (RTB) campaigns in large scale, data freshness is critical so that our users can respond rapidly to changes in campaign performance. We chose Amazon Redshift because of its simplicity, scalability, performance, and ability to load new data in near real time.

Over the past three years, our customer base grew significantly and so did our data. We saw our Amazon Redshift cluster grow from three nodes to 65 nodes. To balance cost and analytics performance, we looked for a way to store large amounts of less-frequently analyzed data at a lower cost. Yet, we still wanted to have the data immediately available for user queries and to meet their expectations for fast performance. We turned to Amazon Redshift Spectrum.

In this post, I explain the reasons why we extended Amazon Redshift with Redshift Spectrum as our modern data warehouse. I cover how our data growth and the need to balance cost and performance led us to adopt Redshift Spectrum. I also share key performance metrics in our environment, and discuss the additional AWS services that provide a scalable and fast environment, with data available for immediate querying by our growing user base.

Amazon Redshift as our foundation

The ability to provide fresh, up-to-the-minute data to our customers and partners was always a main goal with our platform. We saw other solutions provide data that was a few hours old, but this was not good enough for us. We insisted on providing the freshest data possible. For us, that meant loading Amazon Redshift in frequent micro batches and allowing our customers to query Amazon Redshift directly to get results in near real time.

The benefits were immediately evident. Our customers could see how their campaigns performed faster than with other solutions, and react sooner to the ever-changing media supply pricing and availability. They were very happy.

However, this approach required Amazon Redshift to store a lot of data for long periods, and our data grew substantially. In our peak, we maintained a cluster running 65 DC1.large nodes. The impact on our Amazon Redshift cluster was evident, and we saw our CPU utilization grow to 90%.

Why we extended Amazon Redshift to Redshift Spectrum

Redshift Spectrum gives us the ability to run SQL queries using the powerful Amazon Redshift query engine against data stored in Amazon S3, without needing to load the data. With Redshift Spectrum, we store data where we want, at the cost that we want. We have the data available for analytics when our users need it with the performance they expect.

Seamless scalability, high performance, and unlimited concurrency

Scaling Redshift Spectrum is a simple process. First, it allows us to leverage Amazon S3 as the storage engine and get practically unlimited data capacity.

Second, if we need more compute power, we can leverage Redshift Spectrum’s distributed compute engine over thousands of nodes to provide superior performance – perfect for complex queries running against massive amounts of data.

Third, all Redshift Spectrum clusters access the same data catalog so that we don’t have to worry about data migration at all, making scaling effortless and seamless.

Lastly, since Redshift Spectrum distributes queries across potentially thousands of nodes, they are not affected by other queries, providing much more stable performance and unlimited concurrency.

Keeping it SQL

Redshift Spectrum uses the same query engine as Amazon Redshift. This means that we did not need to change our BI tools or query syntax, whether we used complex queries across a single table or joins across multiple tables.

An interesting capability introduced recently is the ability to create a view that spans both Amazon Redshift and Redshift Spectrum external tables. With this feature, you can query frequently accessed data in your Amazon Redshift cluster and less-frequently accessed data in Amazon S3, using a single view.

Leveraging Parquet for higher performance

Parquet is a columnar data format that provides superior performance and allows Redshift Spectrum (or Amazon Athena) to scan significantly less data. With less I/O, queries run faster and we pay less per query. You can read all about Parquet at https://parquet.apache.org/ or https://en.wikipedia.org/wiki/Apache_Parquet.

Lower cost

From a cost perspective, we pay standard rates for our data in Amazon S3, and only small amounts per query to analyze data with Redshift Spectrum. Using the Parquet format, we can significantly reduce the amount of data scanned. Our costs are now lower, and our users get fast results even for large complex queries.

What we learned about Amazon Redshift vs. Redshift Spectrum performance

When we first started looking at Redshift Spectrum, we wanted to put it to the test. We wanted to know how it would compare to Amazon Redshift, so we looked at two key questions:

  1. What is the performance difference between Amazon Redshift and Redshift Spectrum on simple and complex queries?
  2. Does the data format impact performance?

During the migration phase, we had our dataset stored in Amazon Redshift and S3 as CSV/GZIP and as Parquet file formats. We tested three configurations:

  • Amazon Redshift cluster with 28 DC1.large nodes
  • Redshift Spectrum using CSV/GZIP
  • Redshift Spectrum using Parquet

We performed benchmarks for simple and complex queries on one month’s worth of data. We tested how much time it took to perform the query, and how consistent the results were when running the same query multiple times. The data we used for the tests was already partitioned by date and hour. Properly partitioning the data improves performance significantly and reduces query times.

Simple query

First, we tested a simple query aggregating billing data across a month:

SELECT 
  user_id, 
  count(*) AS impressions, 
  SUM(billing)::decimal /1000000 AS billing 
FROM <table_name> 
WHERE 
  date >= '2017-08-01' AND 
  date <= '2017-08-31'  
GROUP BY 
  user_id;

We ran the same query seven times and measured the response times (red marking the longest time and green the shortest time):

Execution Time (seconds)
  Amazon Redshift Redshift Spectrum
CSV
Redshift Spectrum Parquet
Run #1 39.65 45.11 11.92
Run #2 15.26 43.13 12.05
Run #3 15.27 46.47 13.38
Run #4 21.22 51.02 12.74
Run #5 17.27 43.35 11.76
Run #6 16.67 44.23 13.67
Run #7 25.37 40.39 12.75
Average 21.53  44.82 12.61

For simple queries, Amazon Redshift performed better than Redshift Spectrum, as we thought, because the data is local to Amazon Redshift.

What was surprising was that using Parquet data format in Redshift Spectrum significantly beat ‘traditional’ Amazon Redshift performance. For our queries, using Parquet data format with Redshift Spectrum delivered an average 40% performance gain over traditional Amazon Redshift. Furthermore, Redshift Spectrum showed high consistency in execution time with a smaller difference between the slowest run and the fastest run.

Comparing the amount of data scanned when using CSV/GZIP and Parquet, the difference was also significant:

Data Scanned (GB)
CSV (Gzip) 135.49
Parquet 2.83

Because we pay only for the data scanned by Redshift Spectrum, the cost saving of using Parquet is evident and substantial.

Complex query

Next, we compared the same three configurations with a complex query.

Execution Time (seconds)
  Amazon Redshift Redshift Spectrum CSV Redshift Spectrum Parquet
Run #1 329.80 84.20 42.40
Run #2 167.60 65.30 35.10
Run #3 165.20 62.20 23.90
Run #4 273.90 74.90 55.90
Run #5 167.70 69.00 58.40
Average 220.84 71.12 43.14

This time, Redshift Spectrum using Parquet cut the average query time by 80% compared to traditional Amazon Redshift!

Bottom line: For complex queries, Redshift Spectrum provided a 67% performance gain over Amazon Redshift. Using the Parquet data format, Redshift Spectrum delivered an 80% performance improvement over Amazon Redshift. For us, this was substantial.

Optimizing the data structure for different workloads

Because the cost of S3 is relatively inexpensive and we pay only for the data scanned by each query, we believe that it makes sense to keep our data in different formats for different workloads and different analytics engines. It is important to note that we can have any number of tables pointing to the same data on S3. It all depends on how we partition the data and update the table partitions.

Data permutations

For example, we have a process that runs every minute and generates statistics for the last minute of data collected. With Amazon Redshift, this would be done by running the query on the table with something as follows:

SELECT 
  user, 
  COUNT(*) 
FROM 
  events_table 
WHERE 
  ts BETWEEN ‘2017-08-01 14:00:00’ AND ‘2017-08-01 14:00:59’ 
GROUP BY 
  user;

(Assuming ‘ts’ is your column storing the time stamp for each event.)

With Redshift Spectrum, we pay for the data scanned in each query. If the data is partitioned by the minute instead of the hour, a query looking at one minute would be 1/60th the cost. If we use a temporary table that points only to the data of the last minute, we save that unnecessary cost.

Creating Parquet data efficiently

On the average, we have 800 instances that process our traffic. Each instance sends events that are eventually loaded into Amazon Redshift. When we started three years ago, we would offload data from each server to S3 and then perform a periodic copy command from S3 to Amazon Redshift.

Recently, Amazon Kinesis Firehose added the capability to offload data directly to Amazon Redshift. While this is now a viable option, we kept the same collection process that worked flawlessly and efficiently for three years.

This changed, however, when we incorporated Redshift Spectrum. With Redshift Spectrum, we needed to find a way to:

  • Collect the event data from the instances.
  • Save the data in Parquet format.
  • Partition the data effectively.

To accomplish this, we save the data as CSV and then transform it to Parquet. The most effective method to generate the Parquet files is to:

  1. Send the data in one-minute intervals from the instances to Kinesis Firehose with an S3 temporary bucket as the destination.
  2. Aggregate hourly data and convert it to Parquet using AWS Lambda and AWS Glue.
  3. Add the Parquet data to S3 by updating the table partitions.

With this new process, we had to give more attention to validating the data before we sent it to Kinesis Firehose, because a single corrupted record in a partition fails queries on that partition.

Data validation

To store our click data in a table, we considered the following SQL create table command:

create external TABLE spectrum.blog_clicks (
    user_id varchar(50),
    campaign_id varchar(50),
    os varchar(50),
    ua varchar(255),
    ts bigint,
    billing float
)
partitioned by (date date, hour smallint)  
stored as parquet
location 's3://nuviad-temp/blog/clicks/';

The above statement defines a new external table (all Redshift Spectrum tables are external tables) with a few attributes. We stored ‘ts’ as a Unix time stamp and not as Timestamp, and billing data is stored as float and not decimal (more on that later). We also said that the data is partitioned by date and hour, and then stored as Parquet on S3.

First, we need to get the table definitions. This can be achieved by running the following query:

SELECT 
  * 
FROM 
  svv_external_columns 
WHERE 
  tablename = 'blog_clicks';

This query lists all the columns in the table with their respective definitions:

schemaname tablename columnname external_type columnnum part_key
spectrum blog_clicks user_id varchar(50) 1 0
spectrum blog_clicks campaign_id varchar(50) 2 0
spectrum blog_clicks os varchar(50) 3 0
spectrum blog_clicks ua varchar(255) 4 0
spectrum blog_clicks ts bigint 5 0
spectrum blog_clicks billing double 6 0
spectrum blog_clicks date date 7 1
spectrum blog_clicks hour smallint 8 2

Now we can use this data to create a validation schema for our data:

const rtb_request_schema = {
    "name": "clicks",
    "items": {
        "user_id": {
            "type": "string",
            "max_length": 100
        },
        "campaign_id": {
            "type": "string",
            "max_length": 50
        },
        "os": {
            "type": "string",
            "max_length": 50            
        },
        "ua": {
            "type": "string",
            "max_length": 255            
        },
        "ts": {
            "type": "integer",
            "min_value": 0,
            "max_value": 9999999999999
        },
        "billing": {
            "type": "float",
            "min_value": 0,
            "max_value": 9999999999999
        }
    }
};

Next, we create a function that uses this schema to validate data:

function valueIsValid(value, item_schema) {
    if (schema.type == 'string') {
        return (typeof value == 'string' && value.length <= schema.max_length);
    }
    else if (schema.type == 'integer') {
        return (typeof value == 'number' && value >= schema.min_value && value <= schema.max_value);
    }
    else if (schema.type == 'float' || schema.type == 'double') {
        return (typeof value == 'number' && value >= schema.min_value && value <= schema.max_value);
    }
    else if (schema.type == 'boolean') {
        return typeof value == 'boolean';
    }
    else if (schema.type == 'timestamp') {
        return (new Date(value)).getTime() > 0;
    }
    else {
        return true;
    }
}

Near real-time data loading with Kinesis Firehose

On Kinesis Firehose, we created a new delivery stream to handle the events as follows:

Delivery stream name: events
Source: Direct PUT
S3 bucket: nuviad-events
S3 prefix: rtb/
IAM role: firehose_delivery_role_1
Data transformation: Disabled
Source record backup: Disabled
S3 buffer size (MB): 100
S3 buffer interval (sec): 60
S3 Compression: GZIP
S3 Encryption: No Encryption
Status: ACTIVE
Error logging: Enabled

This delivery stream aggregates event data every minute, or up to 100 MB, and writes the data to an S3 bucket as a CSV/GZIP compressed file. Next, after we have the data validated, we can safely send it to our Kinesis Firehose API:

if (validated) {
    let itemString = item.join('|')+'\n'; //Sending csv delimited by pipe and adding new line

    let params = {
        DeliveryStreamName: 'events',
        Record: {
            Data: itemString
        }
    };

    firehose.putRecord(params, function(err, data) {
        if (err) {
            console.error(err, err.stack);        
        }
        else {
            // Continue to your next step 
        }
    });
}

Now, we have a single CSV file representing one minute of event data stored in S3. The files are named automatically by Kinesis Firehose by adding a UTC time prefix in the format YYYY/MM/DD/HH before writing objects to S3. Because we use the date and hour as partitions, we need to change the file naming and location to fit our Redshift Spectrum schema.

Automating data distribution using AWS Lambda

We created a simple Lambda function triggered by an S3 put event that copies the file to a different location (or locations), while renaming it to fit our data structure and processing flow. As mentioned before, the files generated by Kinesis Firehose are structured in a pre-defined hierarchy, such as:

S3://your-bucket/your-prefix/2017/08/01/20/events-4-2017-08-01-20-06-06-536f5c40-6893-4ee4-907d-81e4d3b09455.gz

All we need to do is parse the object name and restructure it as we see fit. In our case, we did the following (the event is an object received in the Lambda function with all the data about the object written to S3):

/*
	object key structure in the event object:
your-prefix/2017/08/01/20/event-4-2017-08-01-20-06-06-536f5c40-6893-4ee4-907d-81e4d3b09455.gz
	*/

let key_parts = event.Records[0].s3.object.key.split('/'); 

let event_type = key_parts[0];
let date = key_parts[1] + '-' + key_parts[2] + '-' + key_parts[3];
let hour = key_parts[4];
if (hour.indexOf('0') == 0) {
 		hour = parseInt(hour, 10) + '';
}
    
let parts1 = key_parts[5].split('-');
let minute = parts1[7];
if (minute.indexOf('0') == 0) {
        minute = parseInt(minute, 10) + '';
}

Now, we can redistribute the file to the two destinations we need—one for the minute processing task and the other for hourly aggregation:

    copyObjectToHourlyFolder(event, date, hour, minute)
        .then(copyObjectToMinuteFolder.bind(null, event, date, hour, minute))
        .then(addPartitionToSpectrum.bind(null, event, date, hour, minute))
        .then(deleteOldMinuteObjects.bind(null, event))
        .then(deleteStreamObject.bind(null, event))        
        .then(result => {
            callback(null, { message: 'done' });            
        })
        .catch(err => {
            console.error(err);
            callback(null, { message: err });            
        }); 

Kinesis Firehose stores the data in a temporary folder. We copy the object to another folder that holds the data for the last processed minute. This folder is connected to a small Redshift Spectrum table where the data is being processed without needing to scan a much larger dataset. We also copy the data to a folder that holds the data for the entire hour, to be later aggregated and converted to Parquet.

Because we partition the data by date and hour, we created a new partition on the Redshift Spectrum table if the processed minute is the first minute in the hour (that is, minute 0). We ran the following:

ALTER TABLE 
  spectrum.events 
ADD partition
  (date='2017-08-01', hour=0) 
  LOCATION 's3://nuviad-temp/events/2017-08-01/0/';

After the data is processed and added to the table, we delete the processed data from the temporary Kinesis Firehose storage and from the minute storage folder.

Migrating CSV to Parquet using AWS Glue and Amazon EMR

The simplest way we found to run an hourly job converting our CSV data to Parquet is using Lambda and AWS Glue (and thanks to the awesome AWS Big Data team for their help with this).

Creating AWS Glue jobs

What this simple AWS Glue script does:

  • Gets parameters for the job, date, and hour to be processed
  • Creates a Spark EMR context allowing us to run Spark code
  • Reads CSV data into a DataFrame
  • Writes the data as Parquet to the destination S3 bucket
  • Adds or modifies the Redshift Spectrum / Amazon Athena table partition for the table
import sys
import sys
from awsglue.transforms import *
from awsglue.utils import getResolvedOptions
from pyspark.context import SparkContext
from awsglue.context import GlueContext
from awsglue.job import Job
import boto3

## @params: [JOB_NAME]
args = getResolvedOptions(sys.argv, ['JOB_NAME','day_partition_key', 'hour_partition_key', 'day_partition_value', 'hour_partition_value' ])

#day_partition_key = "partition_0"
#hour_partition_key = "partition_1"
#day_partition_value = "2017-08-01"
#hour_partition_value = "0"

day_partition_key = args['day_partition_key']
hour_partition_key = args['hour_partition_key']
day_partition_value = args['day_partition_value']
hour_partition_value = args['hour_partition_value']

print("Running for " + day_partition_value + "/" + hour_partition_value)

sc = SparkContext()
glueContext = GlueContext(sc)
spark = glueContext.spark_session
job = Job(glueContext)
job.init(args['JOB_NAME'], args)

df = spark.read.option("delimiter","|").csv("s3://nuviad-temp/events/"+day_partition_value+"/"+hour_partition_value)
df.registerTempTable("data")

df1 = spark.sql("select _c0 as user_id, _c1 as campaign_id, _c2 as os, _c3 as ua, cast(_c4 as bigint) as ts, cast(_c5 as double) as billing from data")

df1.repartition(1).write.mode("overwrite").parquet("s3://nuviad-temp/parquet/"+day_partition_value+"/hour="+hour_partition_value)

client = boto3.client('athena', region_name='us-east-1')

response = client.start_query_execution(
    QueryString='alter table parquet_events add if not exists partition(' + day_partition_key + '=\'' + day_partition_value + '\',' + hour_partition_key + '=' + hour_partition_value + ')  location \'s3://nuviad-temp/parquet/' + day_partition_value + '/hour=' + hour_partition_value + '\'' ,
    QueryExecutionContext={
        'Database': 'spectrumdb'
    },
    ResultConfiguration={
        'OutputLocation': 's3://nuviad-temp/convertresults'
    }
)

response = client.start_query_execution(
    QueryString='alter table parquet_events partition(' + day_partition_key + '=\'' + day_partition_value + '\',' + hour_partition_key + '=' + hour_partition_value + ') set location \'s3://nuviad-temp/parquet/' + day_partition_value + '/hour=' + hour_partition_value + '\'' ,
    QueryExecutionContext={
        'Database': 'spectrumdb'
    },
    ResultConfiguration={
        'OutputLocation': 's3://nuviad-temp/convertresults'
    }
)

job.commit()

Note: Because Redshift Spectrum and Athena both use the AWS Glue Data Catalog, we could use the Athena client to add the partition to the table.

Here are a few words about float, decimal, and double. Using decimal proved to be more challenging than we expected, as it seems that Redshift Spectrum and Spark use them differently. Whenever we used decimal in Redshift Spectrum and in Spark, we kept getting errors, such as:

S3 Query Exception (Fetch). Task failed due to an internal error. File 'https://s3-external-1.amazonaws.com/nuviad-temp/events/2017-08-01/hour=2/part-00017-48ae5b6b-906e-4875-8cde-bc36c0c6d0ca.c000.snappy.parquet has an incompatible Parquet schema for column 's3://nuviad-events/events.lat'. Column type: DECIMAL(18, 8), Parquet schema:\noptional float lat [i:4 d:1 r:0]\n (https://s3-external-1.amazonaws.com/nuviad-temp/events/2017-08-01/hour=2/part-00017-48ae5b6b-906e-4875-8cde-bc36c0c6d0ca.c000.snappy.parq

We had to experiment with a few floating-point formats until we found that the only combination that worked was to define the column as double in the Spark code and float in Spectrum. This is the reason you see billing defined as float in Spectrum and double in the Spark code.

Creating a Lambda function to trigger conversion

Next, we created a simple Lambda function to trigger the AWS Glue script hourly using a simple Python code:

import boto3
import json
from datetime import datetime, timedelta
 
client = boto3.client('glue')
 
def lambda_handler(event, context):
    last_hour_date_time = datetime.now() - timedelta(hours = 1)
    day_partition_value = last_hour_date_time.strftime("%Y-%m-%d") 
    hour_partition_value = last_hour_date_time.strftime("%-H") 
    response = client.start_job_run(
    JobName='convertEventsParquetHourly',
    Arguments={
         '--day_partition_key': 'date',
         '--hour_partition_key': 'hour',
         '--day_partition_value': day_partition_value,
         '--hour_partition_value': hour_partition_value
         }
    )

Using Amazon CloudWatch Events, we trigger this function hourly. This function triggers an AWS Glue job named ‘convertEventsParquetHourly’ and runs it for the previous hour, passing job names and values of the partitions to process to AWS Glue.

Redshift Spectrum and Node.js

Our development stack is based on Node.js, which is well-suited for high-speed, light servers that need to process a huge number of transactions. However, a few limitations of the Node.js environment required us to create workarounds and use other tools to complete the process.

Node.js and Parquet

The lack of Parquet modules for Node.js required us to implement an AWS Glue/Amazon EMR process to effectively migrate data from CSV to Parquet. We would rather save directly to Parquet, but we couldn’t find an effective way to do it.

One interesting project in the works is the development of a Parquet NPM by Marc Vertes called node-parquet (https://www.npmjs.com/package/node-parquet). It is not in a production state yet, but we think it would be well worth following the progress of this package.

Timestamp data type

According to the Parquet documentation, Timestamp data are stored in Parquet as 64-bit integers. However, JavaScript does not support 64-bit integers, because the native number type is a 64-bit double, giving only 53 bits of integer range.

The result is that you cannot store Timestamp correctly in Parquet using Node.js. The solution is to store Timestamp as string and cast the type to Timestamp in the query. Using this method, we did not witness any performance degradation whatsoever.

Lessons learned

You can benefit from our trial-and-error experience.

Lesson #1: Data validation is critical

As mentioned earlier, a single corrupt entry in a partition can fail queries running against this partition, especially when using Parquet, which is harder to edit than a simple CSV file. Make sure that you validate your data before scanning it with Redshift Spectrum.

Lesson #2: Structure and partition data effectively

One of the biggest benefits of using Redshift Spectrum (or Athena for that matter) is that you don’t need to keep nodes up and running all the time. You pay only for the queries you perform and only for the data scanned per query.

Keeping different permutations of your data for different queries makes a lot of sense in this case. For example, you can partition your data by date and hour to run time-based queries, and also have another set partitioned by user_id and date to run user-based queries. This results in faster and more efficient performance of your data warehouse.

Storing data in the right format

Use Parquet whenever you can. The benefits of Parquet are substantial. Faster performance, less data to scan, and much more efficient columnar format. However, it is not supported out-of-the-box by Kinesis Firehose, so you need to implement your own ETL. AWS Glue is a great option.

Creating small tables for frequent tasks

When we started using Redshift Spectrum, we saw our Amazon Redshift costs jump by hundreds of dollars per day. Then we realized that we were unnecessarily scanning a full day’s worth of data every minute. Take advantage of the ability to define multiple tables on the same S3 bucket or folder, and create temporary and small tables for frequent queries.

Lesson #3: Combine Athena and Redshift Spectrum for optimal performance

Moving to Redshift Spectrum also allowed us to take advantage of Athena as both use the AWS Glue Data Catalog. Run fast and simple queries using Athena while taking advantage of the advanced Amazon Redshift query engine for complex queries using Redshift Spectrum.

Redshift Spectrum excels when running complex queries. It can push many compute-intensive tasks, such as predicate filtering and aggregation, down to the Redshift Spectrum layer, so that queries use much less of your cluster’s processing capacity.

Lesson #4: Sort your Parquet data within the partition

We achieved another performance improvement by sorting data within the partition using sortWithinPartitions(sort_field). For example:

df.repartition(1).sortWithinPartitions("campaign_id")…

Conclusion

We were extremely pleased with using Amazon Redshift as our core data warehouse for over three years. But as our client base and volume of data grew substantially, we extended Amazon Redshift to take advantage of scalability, performance, and cost with Redshift Spectrum.

Redshift Spectrum lets us scale to virtually unlimited storage, scale compute transparently, and deliver super-fast results for our users. With Redshift Spectrum, we store data where we want at the cost we want, and have the data available for analytics when our users need it with the performance they expect.


About the Author

With 7 years of experience in the AdTech industry and 15 years in leading technology companies, Rafi Ton is the founder and CEO of NUVIAD. He enjoys exploring new technologies and putting them to use in cutting edge products and services, in the real world generating real money. Being an experienced entrepreneur, Rafi believes in practical-programming and fast adaptation of new technologies to achieve a significant market advantage.

 

 

Ислямските терористи – как да ги разпознаем

Post Syndicated from Григор original http://www.gatchev.info/blog/?p=2100

Преди няколко дни Ислямска държава извърши пореден терористичен атентат.

Ако не сте следили внимателно медиите, може и да сте го пропуснали – повечето го споменаха, но някак с половин уста. За разлика от атентатите в Европа. И дори от атентата срещу руския самолет, в същата държава и кажи-речи на същото място… Става дума за атентата в Египет, в Синай.

Като начало, да се почуди човек откъде дойде този атентат. В Египет хич нямат толерантност към „меките китки“ и подобни. Нито пък приемат бежанци на тонове. Е кой тогава взе, та изби над триста души? Не би трябвало да има кой. Поне ако съдим по преобладаващото сред българите мнение кой и най-вече защо прави атентати в Европа.

А, то имало. Египет е ислямска държава, следователно Ислямска държава направо царува там. Как няма да има кой?… Само че пък възниква въпросът – кого са избили? Понеже, видите ли, атентатът е извършен в джамия. И избитите са се били събрали да се молят там. Мъчи ме подозрение – дали случайно не са били мюсюлмани?

… Още много горчив сарказъм може да се изсипе върху масовите ни заблуди, но надали ще ни излекува. По-добре нека си кажем нещата право в очите.

Атентати на Ислямска държава в Европа или САЩ се вършат към по веднъж годишно, и обикновено отнемат средно по десетина живота. (Не-мюсюлманските атентати, от сорта на този на Брайвик, този в Лас Вегас, този в Орландо отнемат по доста повече.) Атентатите на Ислямска държава в различни ислямски държави са почти ежедневие, и отнемат средно по повече животи. Към 99% от жертвите на атентати на Ислямска държава са мюсюлмани.

Като изключим по някоя и друга бомбардировка от руски или американски самолети, всички реално воюващи с Ислямска държава – иракчани, кюрди, сирийци, турци, иранци – са мюсюлмани. Почти 100% от тези, които реално се бият и рискуват живота си срещу Ислямска държава са мюсюлмани. (Сред жертвите – също.) Немюсюлманите предимно се тупаме по гърдите и приказваме големи приказки. На маса или пред медиите.

На всеки проведен атентат на Ислямска държава в Европа и САЩ се падат купища успешно осуетени от местните власти. Благодарение на информация откъде, би се запитал разсъдливият? В 95% от случаите информацията за някой радикализиран и подготвящ атентат я подават мюсюлмани. Въпреки че в повечето европейски държави са нищожно малцинство – даже в „тотално ислямизираната“ Франция са едва 5% от населението…

И какво се оказва, като погледнем реалността? Основно – да не кажа почти само – потърпевши от Ислямска държава са обикновените мюсюлмани. И пак те са най-решителният, действен и резултатен враг на Ислямска държава. Този, който изнася на гърба си и плаща с кръвта си войната срещу нея.

При това положение колко умна е пропагандата, че всички мюсюлмани са ислямски екстремисти, и най-вече тези дето бягат от Ислямска държава? И колко мъдро е зорлем да се мъчим да отблъснем обикновените мюсюлмани и насила да ги натикаме в обятията на ислямския тероризъм?… Да го вярват искрено пропагандистите не вярвам. Ако наистина бяха чак такива идиоти, нямаше да могат да говорят. Да не говорим за писане на статии, коментари и прочее.

А другата възможност е само една. Както обича да казва Шерлок Холмс, махнете невъзможното и остава истината, колкото и невероятно да звучи.

Накратко – ето ви начинът да разпознаете ислямските терористи и техните помощници. Те са тези, които твърдят, че всеки мюсюлманин или бежанец е потенциален терорист.

—-

След атентата срещу Шарли Ебдо оставих цветенца пред френското посолство. След атентата срещу руския самолет не смогнах да оставя и пред руското посолство, за мой срам. Дано утре или други ден успея да мина и да оставя пред египетското посолство. (То е на улица „6 септември“, точно срещу градинката на „Кристал“, с паметника на Стефан Стамболов.)

Въпрос на човечност е – а тя е въпрос на самоуважение.

Към създаването на Европейско пространство на образование до 2025 г.

Post Syndicated from nellyo original https://nellyo.wordpress.com/2017/11/26/2025/

Европейската комисия излага своята визия за това как  да се създаде Европейско пространство на образование до 2025 г. Целите  са наистина много амбициозни и има смисъл да стигнат до повече хора, ето част от прессъобщението:

На своята среща в Рим през март 2017 г. лидерите на Европа поеха ангажимент за създаването на „Съюз, в който младите хора получават най-доброто образование и обучение и могат да следват и да намират работа навсякъде на континента“. Комисията е убедена, че образованието и културата могат да бъдат важна част от решението за преодоляване на предизвикателствата, свързани със застаряването на работната сила, продължаващата цифровизация, бъдещите нужди от умения, необходимостта да се насърчават критичното мислене и медийната грамотност в епоха, в която могат да се разпространяват „алтернативни факти“ и дезинформация онлайн, както и нуждата да се подхранва по-силно чувство на принадлежност предвид предизвикателството на популизма и ксенофобията.

Европейското пространство на образование следва да включва следното:

  • Превръщане на мобилността в реалност за всички: доразвиване на положителния опит от програма „Еразъм +“ и Европейския корпус за солидарност и разширяване на участието в тях, както и създаване на студентска карта на ЕС, за да се предложи нов, лесен за ползване начин за съхраняване на информацията за академичните резултати на дадено лице;
  • Взаимно признаване на дипломи:започване на нов „Сорбонски процес“, въз основа на процеса от Болоня, за да се подготви почвата за взаимно признаване на дипломите за средно и висше образование;
  • По-голямо сътрудничество при разработването на учебни планове: отправяне на препоръки, за да се гарантира, че образователните системи предоставят всички знания, умения и компетентности, които са от първостепенно значение в днешния свят;
  • Подобряване на изучаването на езици: определяне на нова цел до 2025 г. всички млади европейци, които завършват гимназиален етап на средното образование, да имат добри познания по два езика в допълнение към майчиния си език (езици);
  • Насърчаване на ученето през целия живот: стремеж към сближаване и увеличаване на броя на хората, участващи в учене през целия живот, за да се постигне целта от 25 % до 2025 г.;
  • Интегриране на иновациите и цифровите технологии в образованието: насърчаване на новаторско и цифрово обучение и разработване на нов План за действие за цифрово образование;
  • Подкрепа за преподавателите: увеличаване на броя на преподавателите, участващи в програма „Еразъм+“ и мрежата eTwinning, и предоставяне на насоки за политиката относно професионалното развитие на преподавателите и училищните ръководители;
  • Създаване на мрежа от европейски университети, така че европейските университети от световна класа да могат да си сътрудничат безпрепятствено през границите, както и подкрепа за създаването на Училище по европейско и транснационално управление;
  • Инвестиране в образованието: използване на Европейския семестър в подкрепа на структурните реформи за подобряване на образователната политика, използване на финансиране от ЕС и на инвестиционните инструменти на ЕС за финансиране на образованието, както и определяне на референтна цел за държавите членки да инвестират 5 % от БВП в образованието.
  • Опазване на културното наследство и насърчаване на чувството за европейска идентичност и култура: разработване, благодарение на динамиката, набрана през Европейската година на културното наследство — 2018 г., на Европейска програма за култура и изготвяне на препоръка на Съвета относно общите ценности, приобщаващото образование и европейското измерение на преподаването.
  • Засилване на европейското измерение на Euronews, създадена през 1993 г. от редица европейски обществени радио- и телевизионни оператори с амбицията тази медия да се превърне в европейски канал, който дава достъп до независима, висококачествена информация от паневропейска перспектива.

Filed under: Digital, EU Law