#CheckTime | Explore Tumblr posts and blogs

jmtapio · 6 years ago

Link

An increasingly popular design for a datacenter network is BGP on the host: each host ships with a BGP daemon to advertise the IPs it handles and receives the routes to its fellow servers. Compared to a L2-based design, it is very scalable, resilient, cross-vendor and safe to operate.1 Take a look at “L3 routing to the hypervisor with BGP” for a usage example.

BGP on the host with a spine-leaf IP fabric. A BGP session is established over each link and each host advertises its own IP prefixes.

While routing on the host eliminates the security problems related to Ethernet networks, a server may announce any IP prefix. In the above picture, two of them are announcing 2001:db8:cc::/64. This could be a legit use of anycast or a prefix hijack. BGP offers several solutions to improve this aspect and one of them is to reuse the features around the RPKI.

Short introduction to the RPKI

On the Internet, BGP is mostly relying on trust. This contributes to various incidents due to operator errors, like the one that affected Cloudflare a few months ago, or to malicious attackers, like the hijack of Amazon DNS to steal cryptocurrency wallets. RFC 7454 explains the best practices to avoid such issues.

IP addresses are allocated by five Regional Internet Registries (RIR). Each of them maintains a database of the assigned Internet resources, notably the IP addresses and the associated AS numbers. These databases may not be totally reliable but are widely used to build ACLs to ensure peers only announce the prefixes they are expected to. Here is an example of ACLs generated by bgpq3 when peering directly with Apple:2

$ bgpq3 -l v6-IMPORT-APPLE -6 -R 48 -m 48 -A -J -E AS-APPLE policy-options { policy-statement v6-IMPORT-APPLE { replace: from { route-filter 2403:300::/32 upto /48; route-filter 2620:0:1b00::/47 prefix-length-range /48-/48; route-filter 2620:0:1b02::/48 exact; route-filter 2620:0:1b04::/47 prefix-length-range /48-/48; route-filter 2620:149::/32 upto /48; route-filter 2a01:b740::/32 upto /48; route-filter 2a01:b747::/32 upto /48; } } }

The RPKI (RFC 6480) adds public-key cryptography on top of it to sign the authorization for an AS to be the origin of an IP prefix. Such record is a Route Origination Authorization (ROA). You can browse the databases of these ROAs through the RIPE’s RPKI Validator instance:

RPKI validator shows one ROA for 85.190.88.0/21

BGP daemons do not have to download the databases or to check digital signatures to validate the received prefixes. Instead, they offload these tasks to a local RPKI validator implementing the “RPKI-to-Router Protocol” (RTR, RFC 6810).

For more details, have a look at “RPKI and BGP: our path to securing Internet Routing.”

Using origin validation in the datacenter

While it is possible to create our own RPKI for use inside the datacenter, we can take a shortcut and use a validator implementing RTR, like GoRTR, and accepting another source of truth. Let’s work on the following topology:

BGP on the host with prefix validation using RTR. Each server has its own AS number. The leaf routers establish RTR sessions to the validators.

You assume we have a place to maintain a mapping between the private AS numbers used by each host and the allowed prefixes:3

ASN Allowed prefixes AS 65005 2001:db8:aa::/64 AS 65006 2001:db8:bb::/64, 2001:db8:11::/64 AS 65007 2001:db8:cc::/64 AS 65008 2001:db8:dd::/64 AS 65009 2001:db8:ee::/64, 2001:db8:11::/64 AS 65010 2001:db8:ff::/64

From this table, we build a JSON file for GoRTR, assuming each host can announce the provided prefixes or longer ones (like 2001:db8:aa::42:d9ff:fefc:287a/128 for AS 65005):

{ "roas": [ { "prefix": "2001:db8:aa::/64", "maxLength": 128, "asn": "AS65005" }, { "…": "…" }, { "prefix": "2001:db8:ff::/64", "maxLength": 128, "asn": "AS65010" }, { "prefix": "2001:db8:11::/64", "maxLength": 128, "asn": "AS65006" }, { "prefix": "2001:db8:11::/64", "maxLength": 128, "asn": "AS65009" } ] }

This file is deployed to all validators and served by a web server. GoRTR is configured to fetch it and update it every 10 minutes:

$ gortr -refresh=600 \ -verify=false -checktime=false \ -cache=http://127.0.0.1/rpki.json INFO[0000] New update (7 uniques, 8 total prefixes). 0 bytes. Updating sha256 hash -> 68a1d3b52db8d654bd8263788319f08e3f5384ae54064a7034e9dbaee236ce96 INFO[0000] Updated added, new serial 1

The refresh time could be lowered but GoRTR can be notified of an update using the SIGHUP signal. Clients are immediately notified of the change.

The next step is to configure the leaf routers to validate the received prefixes using the farm of validators. Most vendors support RTR:

Platform Over TCP? Over SSH? Juniper JunOS ✔️ ❌ Cisco IOS XR ✔️ ✔️ Cisco IOS XE ✔️ ❌ Cisco IOS ✔️ ❌ Arista EOS ❌ ❌ BIRD ✔️ ✔️ FRR ✔️ ✔️ GoBGP ✔️ ❌

Configuring JunOS

JunOS only supports plain-text TCP. First, let’s configure the connections to the validation servers:

routing-options { validation { group RPKI { session validator1 { hold-time 60; # session is considered down after 1 minute record-lifetime 3600; # cache is kept for 1 hour refresh-time 30; # cache is refreshed every 30 seconds port 8282; } session validator2 { /* OMITTED */ } session validator3 { /* OMITTED */ } } } }

By default, at most two sessions are randomly established at the same time. This provides a good way to load-balance them among the validators while maintaining good availability. The second step is to define the policy for route validation:

policy-options { policy-statement ACCEPT-VALID { term valid { from { protocol bgp; validation-database valid; } then { validation-state valid; accept; } } term invalid { from { protocol bgp; validation-database invalid; } then { validation-state invalid; reject; } } } policy-statement REJECT-ALL { then reject; } }

The policy statement ACCEPT-VALID turns the validation state of a prefix from unknown to valid if the ROA database says it is valid. It also accepts the route. If the prefix is invalid, the prefix is marked as such and rejected. We have also prepared a REJECT-ALL statement to reject everything else, notably unknown prefixes.

A ROA only certifies the origin of a prefix. A malicious actor can therefore prepend the expected AS number to the AS path to circumvent the validation. For example, AS 65007 could annonce 2001:db8:dd::/64, a prefix allocated to AS 65006, by advertising it with the AS path 65007 65006. To avoid that, we define an additional policy statement to reject AS paths with more than one AS:

policy-options { as-path EXACTLY-ONE-ASN "^.$"; policy-statement ONLY-DIRECTLY-CONNECTED { term exactly-one-asn { from { protocol bgp; as-path EXACTLY-ONE-ASN; } then next policy; } then reject; } }

The last step is to configure the BGP sessions:

protocols { bgp { group HOSTS { local-as 65100; type external; # export [ … ]; import [ ONLY-DIRECTLY-CONNECTED ACCEPT-VALID REJECT-ALL ]; enforce-first-as; neighbor 2001:db8:42::a10 { peer-as 65005; } neighbor 2001:db8:42::a12 { peer-as 65006; } neighbor 2001:db8:42::a14 { peer-as 65007; } } } }

The import policy rejects any AS path longer than one AS, accepts any validated prefix and rejects everything else. The enforce-first-as directive is also pretty important: it ensures the first (and, here, only) AS in the AS path matches the peer AS. Without it, a malicious neighbor could inject a prefix using an AS different than its own, defeating our purpose.4

Let’s check the state of the RTR sessions and the database:

> show validation session Session State Flaps Uptime #IPv4/IPv6 records 2001:db8:4242::10 Up 0 00:16:09 0/9 2001:db8:4242::11 Up 0 00:16:07 0/9 2001:db8:4242::12 Connect 0 0/0 > show validation database RV database for instance master Prefix Origin-AS Session State Mismatch 2001:db8:11::/64-128 65006 2001:db8:4242::10 valid 2001:db8:11::/64-128 65006 2001:db8:4242::11 valid 2001:db8:11::/64-128 65009 2001:db8:4242::10 valid 2001:db8:11::/64-128 65009 2001:db8:4242::11 valid 2001:db8:aa::/64-128 65005 2001:db8:4242::10 valid 2001:db8:aa::/64-128 65005 2001:db8:4242::11 valid 2001:db8:bb::/64-128 65006 2001:db8:4242::10 valid 2001:db8:bb::/64-128 65006 2001:db8:4242::11 valid 2001:db8:cc::/64-128 65007 2001:db8:4242::10 valid 2001:db8:cc::/64-128 65007 2001:db8:4242::11 valid 2001:db8:dd::/64-128 65008 2001:db8:4242::10 valid 2001:db8:dd::/64-128 65008 2001:db8:4242::11 valid 2001:db8:ee::/64-128 65009 2001:db8:4242::10 valid 2001:db8:ee::/64-128 65009 2001:db8:4242::11 valid 2001:db8:ff::/64-128 65010 2001:db8:4242::10 valid 2001:db8:ff::/64-128 65010 2001:db8:4242::11 valid IPv4 records: 0 IPv6 records: 18

Here is an example of accepted route:

> show route protocol bgp table inet6 extensive all inet6.0: 11 destinations, 11 routes (8 active, 0 holddown, 3 hidden) 2001:db8:bb::42/128 (1 entry, 0 announced) *BGP Preference: 170/-101 Next hop type: Router, Next hop index: 0 Address: 0xd050470 Next-hop reference count: 4 Source: 2001:db8:42::a12 Next hop: 2001:db8:42::a12 via em1.0, selected Session Id: 0x0 State: <Active NotInstall Ext> Local AS: 65006 Peer AS: 65000 Age: 12:11 Validation State: valid Task: BGP_65000.2001:db8:42::a12+179 AS path: 65006 I Accepted Localpref: 100 Router ID: 1.1.1.1

A rejected route would be similar with the reason “rejected by import policy” shown in the details and the validation state would be invalid.

Configuring BIRD

BIRD supports both plain-text TCP and SSH. Let’s configure it to use SSH. We need to generate keypairs for both the leaf router and the validators (they can all share the same keypair). We also have to create a known_hosts file for BIRD:

(validatorX)$ ssh-keygen -qN "" -t rsa -f /etc/gortr/ssh_key (validatorX)$ echo -n "validatorX:8283 " ; \ cat /etc/bird/ssh_key_rtr.pub validatorX:8283 ssh-rsa AAAAB3[…]Rk5TW0= (leaf1)$ ssh-keygen -qN "" -t rsa -f /etc/bird/ssh_key (leaf1)$ echo 'validator1:8283 ssh-rsa AAAAB3[…]Rk5TW0=' >> /etc/bird/known_hosts (leaf1)$ echo 'validator2:8283 ssh-rsa AAAAB3[…]Rk5TW0=' >> /etc/bird/known_hosts (leaf1)$ cat /etc/bird/ssh_key.pub ssh-rsa AAAAB3[…]byQ7s= (validatorX)$ echo 'ssh-rsa AAAAB3[…]byQ7s=' >> /etc/gortr/authorized_keys

GoRTR needs additional flags to allow connections over SSH:

$ gortr -refresh=600 -verify=false -checktime=false \ -cache=http://127.0.0.1/rpki.json \ -ssh.bind=:8283 \ -ssh.key=/etc/gortr/ssh_key \ -ssh.method.key=true \ -ssh.auth.user=rpki \ -ssh.auth.key.file=/etc/gortr/authorized_keys INFO[0000] Enabling ssh with the following authentications: password=false, key=true INFO[0000] New update (7 uniques, 8 total prefixes). 0 bytes. Updating sha256 hash -> 68a1d3b52db8d654bd8263788319f08e3f5384ae54064a7034e9dbaee236ce96 INFO[0000] Updated added, new serial 1

Then, we can configure BIRD to use these RTR servers:

roa6 table ROA6; template rpki VALIDATOR { roa6 { table ROA6; }; transport ssh { user "rpki"; remote public key "/etc/bird/known_hosts"; bird private key "/etc/bird/ssh_key"; }; refresh keep 30; retry keep 30; expire keep 3600; } protocol rpki VALIDATOR1 from VALIDATOR { remote validator1 port 8283; } protocol rpki VALIDATOR2 from VALIDATOR { remote validator2 port 8283; }

Unlike JunOS, BIRD doesn’t have a feature to only use a subset of validators. Therefore, we only configure two of them. As a safety measure, if both connections become unavailable, BIRD will keep the ROAs for one hour.

We can query the state of the RTR sessions and the database:

> show protocols all VALIDATOR1 Name Proto Table State Since Info VALIDATOR1 RPKI --- up 17:28:56.321 Established Cache server: rpki@validator1:8283 Status: Established Transport: SSHv2 Protocol version: 1 Session ID: 0 Serial number: 1 Last update: before 25.212 s Refresh timer : 4.787/30 Retry timer : --- Expire timer : 3574.787/3600 No roa4 channel Channel roa6 State: UP Table: ROA6 Preference: 100 Input filter: ACCEPT Output filter: REJECT Routes: 9 imported, 0 exported, 9 preferred Route change stats: received rejected filtered ignored accepted Import updates: 9 0 0 0 9 Import withdraws: 0 0 --- 0 0 Export updates: 0 0 0 --- 0 Export withdraws: 0 --- --- --- 0 > show route table ROA6 Table ROA6: 2001:db8:11::/64-128 AS65006 [VALIDATOR1 17:28:56.333] * (100) [VALIDATOR2 17:28:56.414] (100) 2001:db8:11::/64-128 AS65009 [VALIDATOR1 17:28:56.333] * (100) [VALIDATOR2 17:28:56.414] (100) 2001:db8:aa::/64-128 AS65005 [VALIDATOR1 17:28:56.333] * (100) [VALIDATOR2 17:28:56.414] (100) 2001:db8:bb::/64-128 AS65006 [VALIDATOR1 17:28:56.333] * (100) [VALIDATOR2 17:28:56.414] (100) 2001:db8:cc::/64-128 AS65007 [VALIDATOR1 17:28:56.333] * (100) [VALIDATOR2 17:28:56.414] (100) 2001:db8:dd::/64-128 AS65008 [VALIDATOR1 17:28:56.333] * (100) [VALIDATOR2 17:28:56.414] (100) 2001:db8:ee::/64-128 AS65009 [VALIDATOR1 17:28:56.333] * (100) [VALIDATOR2 17:28:56.414] (100) 2001:db8:ff::/64-128 AS65010 [VALIDATOR1 17:28:56.333] * (100) [VALIDATOR2 17:28:56.414] (100)

Like for the JunOS case, a malicious actor could try to workaround the validation by building an AS path where the last AS number is the legitimate one. BIRD is flexible enough to allow us to use any AS to check the IP prefix. Instead of checking the origin AS, we ask it to check the peer AS with this function, without looking at the AS path:

function validated(int peeras) { if (roa_check(ROA6, net, peeras) != ROA_VALID) then { print "Ignore invalid ROA ", net, " for ASN ", peeras; reject; } accept; }

The BGP instance is then configured to use the above function as the import policy:

protocol bgp PEER1 { local as 65100; neighbor 2001:db8:42::a10 as 65005; ipv6 { import keep filtered; import where validated(65005); # export …; }; }

You can view the rejected routes with show route filtered, but BIRD does not store information about the validation state in the routes. You can also watch the logs:

2019-07-31 17:29:08.491 <INFO> Ignore invalid ROA 2001:db8:bb::40:/126 for ASN 65005

Currently, BIRD does not reevaluate the prefixes when the ROAs are updated. There is work in progress to fix this. If this feature is important to you, have a look at FRR instead: it also supports the RTR protocol and triggers a soft reconfiguration of the BGP sessions when ROAs are updated.

Notably, the data flow and the control plane are separated. A node can remove itself by notifying its peers without losing a single packet. ↩︎

People often use AS sets, like AS-APPLE in this example, as they are convenient if you have multiple AS numbers or customers. However, there is currently nothing preventing a rogue actor to add arbitrary AS numbers to their AS set. ↩︎

We are using 16-bit AS numbers for readability. Because we need to assign a different AS number for each host in the datacenter, in an actual deployment, we would use 32-bit AS numbers. ↩︎

Cisco routers and FRR enforce the first AS by default. It is a tunable value to allow the use of route servers: they distribute prefixes on behalf of other routers. ↩︎

via Planet Debian

#Reading

0 notes

examinationresult · 7 years ago

Text

IBPS PO Prelims 2018: Result likely by today, check at ibps.in - The Indian Express

The Indian Express IBPS PO Prelims 2018: Result likely by today, check at ibps.in The Indian Express Speaking to indianexpress.com, an official said, “The results of Probationary Officer prelims examination will be released either on October 30 or 31. The candidates who had appeared in the examination can check the results through the official website ... IBPS PO Prelims result 2018 to be released soon @ ibps.in; know how to checkTimes of India IBPS PO Prelims Result 2018 result release date declaration on ibps.in revealed; check detailsZee Business IBPS PO Prelims Result 2018: Expected Soon @ Ibps.in, Know How To CheckNDTV India Today -Free Press Journal -Oneindia all 16 news articles » ..... Read More

#Exam Result #IBPS PO Prelims 2018: Result likely by today #check at ibps.in - The Indian Express #On

0 notes

cheongtangenterprise · 3 years ago

Text

Best Time Attendance Machine

We Are Provide UF100 uses a Linux operation system, it is stable and reliable. It made of elegant design and professional surface treatment. UF100 is an innovative biometric fingerprint reader for Time Attendance applications, offering unparalleled performance using an advanced algorithm for reliability, precision, and excellent matching speed. The UF100 features the fastest commercial-based fingerprint matching algorithm and a high-performance, high-image quality optical fingerprint sensor. The 2.8inch TFT can display more information vividly, including fingerprint image quality and verification result, etc. Wi-Fi, TCP/IP communication is standard, and make sure the data transmission between terminal and PC can be easily done within several seconds.

Please do not hesitate to call or email for more information. Call/SMS/WhatsApp Tang +60 019-559 7808Email : [email protected] : [email protected] http://www.cte.my

#timeattendancesystem #biometrictimeattendance #uf100 #realtimeattendance #checktime

2 notes · View notes

hodldrgn-blog · 7 years ago

Photo

New Post has been published on https://cryptomoonity.com/eosio-version-1-4-0/

EOSIO Version 1.4.0

EOSIO Version 1.4.0 Release: Deterministic Snapshots, Cloud Server Performance, and updates to the EOSIO Contract Development Toolkit

Today we are pleased to announce the next version of EOSIO, V1.4.0. We have also addressed a major update to the EOSIO.CDT, which you can read more about below. For EOSIO V1.4.0 you can view the detailed release notes here on Github, and find documentation on the EOSIO Developer Portal.

We are continually collecting feedback on how the community is building applications on the platform and are consistently improving the developer experience on EOSIO. Going forward, we will be targeting the second Tuesday of each month (in the middle of the month) for an update to the EOSIO software.

In addition to release notes and documentation, the Block.one Developer Relations team — in coordination with the C++ Development and Marketing & Communications teams — will provide easy-to-digest summaries of the features and benefits of each release and their implications on our goals for the platform.

Continue reading below to learn more about EOSIO V1.4.0 and major updates to the EOSIO Contract Development Toolkit.

Highlights in EOSIO V1.4.0:

Deterministic Snapshots (#5956)

In the EOSIO V1.2.0 release, we introduced Replay and Resync optimizations (#5130) to address the issue that as the blockchain grows, the time needed to set up a new node and replay the chain will also continue to rise. Building on that, in V1.3.0 we introduced more performance enhancements called Trusted Producer Light Validation (#5631).

To complete the journey for new users on-boarding as EOSIO developers, we’ve released the ability to create Snapshots and use them when starting a new node. This will allow regular users to get up and running with EOSIO in just a few minutes instead of spending hours waiting to download the blockchain data and set up their node. Downloading a snapshot of the blockchain offers a verifiable path to having a version of the blockchain from last week or even a few hours ago, for example. From this point, syncing up to the network will bring you up to date with the latest version.

To compliment this feature, we’ve introduce a deterministic integrity hash which can prove that two nodes have exactly the same state. This makes verifying new nodes as easy as fetching a string from a trusted public node and comparing it to the local copy and works whether you use snapshots or not.

Since the release of EOSIO, one of the fastest and most scalable blockchain platforms to date, Block.one has been focused on driving mass adoption for blockchain technology. Simplifying the developer experience and lowering barriers for new developers to adopt the platform remains our primary goal for improvements. Recent releases have following this theme by helping to improve the efficiency of the chain for more performant application development and ease of use for the EOSIO developer community.

Ongoing Performance Improvements

In addition to enhancements to the developer experience on EOSIO, we are making continual progress towards EOSIO staying one of the fastest and most efficient blockchain technologies. In our EOSIO V1.3 release last month we introduced wabt (pronounced “wabbit”), a suite of tools for WebAssembly to replace the existing binaryen interpreter, and saw considerable performance increases. Some block producers, after implementation, were utilizing 50% less CPU resources to run the main EOSIO public blockchain.

Kernel Timer-Based Checktime (#5799)

In this release we’ve optimized how contract execution time is monitored by nodeos. Previously nodeos would frequently poll the operating system to determine if a contract should be interrupted due to exceeding its resource allocation. Now, a timer is used so the operating system asynchronously notifies nodeos it is time to interrupt contract execution. On bare metal hardware this improvement typically provides a performance increase over 10%. On certain cloud server configurations the improvement is even higher.

EOSIO.CDT — Contract Development Toolkit Update

Earlier last week we also released an update to the EOSIO Contract Development Toolkit — you can read more about it here in our initial announcement. EOSIO.CDT provides support for EOSIO smart contract development, utilizing Gnu & C++ 11 style attributes to mark C++ contracts for ABI generation, creating a more flexible and reliable way of declaring your smart contract structure and associated data structures.

There were a number of substantial changes made in last week’s release that we wanted to outline in detail here. One of the main changes is that to support binary releases we needed to remove the concept of a core symbol from EOSIO.CDT. This meant drastic changes to symbol, asset and other types/functions that were connected to them. Since we knew these changes would be disruptive, we decided to add as many as we could in one go, so that the disruption should only occur once. Please be sure to read the Differences between Version 1.2.x and Version 1.3.x section of the readme.

Additional Issues:

A full list of issues for this release can be found in the Official Release Notes.

Stay Connected

If you are interested in providing feedback and working more closely with our team to improve EOSIO for the community, you can send our developer relations team an email at [email protected]. You can also hear about future updates by subscribing to our mailing list on the EOSIO Developer Portal. We are excited to be continually improving the usability of the software for EOSIO developers as we continue laying a foundation for the mass adoption of blockchain technology.

Read disclaimer

EOSIO Version 1.4.0 was originally published in eosio on Medium, where people are continuing the conversation by highlighting and responding to this story.

Source

Unikrn ICO Failed – Mark Cuban Lost Money ... Title: Unikrn ICO Failed - Mark Cuban Lost Money - Now Class Action Lawsuit! Video duration: 4:44 Views: 1457 Likes: 55 Dislikes: 3 Publication da...

EOS Global Hackathon: Meet the Mentors Title: EOS Global Hackathon: Meet the Mentors Video duration: 3:9 Views: 28 Likes: Dislikes: Publication date: 2018-08-29 07:38:28 https://www....

On the RIGHT Side of History – Bitcoin Futu... Title: On the RIGHT Side of History - Bitcoin Future - Price Doesn't Matter! - Video duration: 12:58 Views: 6980 Likes: 361 Dislikes: 23 Publica...

Jonathan Zeppettini (JZ) on Decred Governance Title: Jonathan Zeppettini (JZ) on Decred Governance Video duration: 5:4 Views: 5 Likes: 1 Dislikes: 0 Publication date: 2018-09-13 14:56:59 http...

.yuzo_related_post .relatedthumb background: !important; -webkit-transition: background 0.2s linear; -moz-transition: background 0.2s linear; -o-transition: background 0.2s linear; transition: background 0.2s linear;;color:!important; .yuzo_related_post .relatedthumb:hoverbackground:#fcfcf4 !important;color:!important; .yuzo_related_post .yuzo_text color:!important; .yuzo_related_post .relatedthumb:hover .yuzo_text color:!important; .yuzo_related_post .relatedthumb acolor:!important; .yuzo_related_post .relatedthumb a:hovercolor:!important; .yuzo_related_post .relatedthumb:hover a color:!important; .yuzo_related_post .relatedthumb margin: 0px 0px 0px 0px; padding: 5px 5px 5px 5px;

#Blockchain #Blockone #developer-tools #EOSIO #technology

0 notes

denisemorais · 6 years ago

Video

View this post on Instagram

A post shared by denise morais (@denisemorais)

instagram

#Inverno19 @shantefashionoficial #checktime #xadrez #carrotpants #tops #cardigans #canelados #trendalert #diadasmaes (em Shante Fashion) https://www.instagram.com/p/Bwpbzc0H4yJ/?utm_source=ig_tumblr_share&igshid=1g7g5muxw9gdb

#inverno19 #checktime #xadrez #carrotpants #tops #cardigans #canelados #trendalert #diadasmaes

0 notes

loveconquers13 · 7 years ago

Photo

The #Train from #Ayutthaya to #Bangkok #HuaLamphongTrainStation No #AirCondition, only with #Fans #20130515 #Travel #StateRailwayOfThailand #Thailand #Apple #iPhone5 #Instagram #IG #Filters #曼谷 #大城 #泰國 #大城火車站 #華藍蓬火車站 Thailand Railway check #Timetable & #Fares http://www.railway.co.th/checktime/checktime.asp?lenguage=Eng (at Ayutthaya, Thailand)

0 notes

oua-ap · 8 years ago

Text

[Sample]時計を作る

時間を調べる

void setup() {

size( 500, 500 ); }

void draw() { background( 255 );

int hour = hour();//時間を取得 int minute = minute();//分を取得 int second = second();//秒を取得 println( hour + ":" + minute + ":" + second );

}

針を描く

void setup() { size( 500, 500 ); frameRate( 1 ); }

void draw() { background( 255 );

int hour = hour(); int minute = minute(); int second = second(); println( hour + ":" + minute + ":" + second );

float secondAngle = second/60.0 * 360;//角度を求める pushMatrix();//座標を記憶 translate( width/2, height/2 );//画面の中心に移動 rotate( radians( secondAngle) );//求めた角度を回転 stroke( 255, 0, 0); strokeWeight(1); line( 0, 0, 0, -200 );//200pxの長さの線を描く popMatrix();

float minuteAngle = minute/60.0 * 360; pushMatrix(); translate( width/2, height/2 ); rotate( radians( minuteAngle) ); stroke(0); strokeWeight(3); line( 0, 0, 0, -200 ); popMatrix();

float hourAngle = (hour%12)/12.0 * 360; hourAngle += 30*(minuteAngle/360.0);//分針の進みを時針に加える pushMatrix(); translate( width/2, height/2 ); rotate( radians( hourAngle) ); stroke( 0 ); strokeWeight(7); line( 0, 0, 0, -150 ); popMatrix(); }

文字盤を描く

void setup() { size( 500, 500 ); }

void draw() { background( 255 );

int hour = hour(); int minute = minute(); int second = second(); println( hour + ":" + minute + ":" + second );

float secondAngle = second/60.0 * 360; pushMatrix(); translate( width/2, height/2 ); rotate( radians( secondAngle) ); stroke( 255, 0, 0); strokeWeight(1); line( 0, 0, 0, -200 ); popMatrix();

float minuteAngle = minute/60.0 * 360; pushMatrix(); translate( width/2, height/2 ); rotate( radians( minuteAngle) ); stroke(0); strokeWeight(3); line( 0, 0, 0, -200 ); popMatrix();

for ( int i=1; i<=12; i++) {//1~12まで繰り返す //三角関数で角度からX,Y座標を求める float x = cos( radians( i*30 - 90) ) * 200 + width/2; float y = sin( radians( i*30 - 90) ) * 200 + height/2; fill( 0 ); text( i, x, y );//文字を書く } }

ワーク：変な時計を作ろう

void setup() { size( 500, 500 ); noStroke(); colorMode(HSB, 360, 100, 100, 100); }

void draw() { background( 0, 0, 100 );

float hour = hour(); float minute = minute(); float second = second(); println( hour + ":" + minute + ":" + second );

hour = map( hour, 0, 24, 0, 100 );//0~24を0~100に変換 minute = map( minute, 0, 60, 0, 100 );//0~60を0~100に変換 second = map( second, 0, 60, 0, 360 );//0~60を0~360に変換 color watchColor = color( second, minute, hour);//塗り色に指定

fill( watchColor ) ; ellipse( width/2, height/2, 400, 400 ); }

void setup() { size( 500, 500 ); noStroke(); colorMode(HSB, 360, 100, 100, 100); rectMode( CENTER ); }

void draw() { background( 0, 0, 100 );

float hour = hour(); float minute = minute(); float second = second(); println( hour + ":" + minute + ":" + second );

hour = map( hour, 0, 24, 0, 360 );//0~24を0~360に変換 minute = map( minute, 0, 60, 0, width );//0~60を0~255に変換 second = map( second, 0, 60, 0, height );//0~60を0~255に変換 color watchColor = color( hour, 100, 100, 100 );//塗り色に指定

fill( watchColor ) ; rect( width/2, height/2, minute, second );

}

ArrayList<Mover> movers = new ArrayList<Mover>();

void setup() { size( 500, 500 ); colorMode(HSB, 360, 100, 100, 100); background( 0, 0, 100); }

void draw() { noStroke(); fill( 0, 0, 100, 2 ); rect( 0, 0, width, height);

float hour = hour(); float minute = minute(); float second = second();

float secondAngle = second/60.0 * 360;//角度を求める float minuteAngle = minute/60.0 * 360; float hourAngle = (hour%12)/12.0 * 360; hourAngle += 30*(minuteAngle/360.0);//分針の進みを時針に加える

// sec PVector p = new PVector( width/2.0, height/2.0); float x = cos( radians(secondAngle-90) ); float y = sin( radians(secondAngle-90) ); PVector v = new PVector( x, y ); color c = color(50, 50, 100, 100); float s = 20; movers.add( new Mover( p, v, c, s )); if ( movers.size() > 1000 ) movers.remove(0);

// min PVector mp = new PVector( width/2.0, height/2.0); float mx = cos( radians(minuteAngle-90) ) ; float my = sin( radians(minuteAngle-90) ) ; PVector mv = new PVector( mx, my ); color mc = color(170, 50, 100, 100); color ms = 20; movers.add( new Mover( mp, mv, mc, ms )); if ( movers.size() > 1000 ) movers.remove(0);

// hour PVector hp = new PVector( width/2.0, height/2.0); float hx = cos( radians(hourAngle-90) ) ; float hy = sin( radians(hourAngle-90) ) ; PVector hv = new PVector( hx, hy ); color hc = color(290, 50, 100, 100); color hs = 20; movers.add( new Mover( hp, hv, hc, hs )); if ( movers.size() > 1000 ) movers.remove(0);

for ( Mover m : movers) { m.update(); m.display(); } filter( BLUR, 3 ); }

class Mover { PVector pos; PVector vec; color mycolor; float scale;

Mover( PVector _pos, PVector _vec, color _color, float _scale) { pos = _pos; vec = _vec; mycolor = _color; scale = _scale; }

void update() { pos.add(vec); }

void display() { fill( mycolor ); ellipse( pos.x, pos.y, scale, scale ); } }

dataフォルダにパーティクルの画像"dot.png"とフォントデータ”FrutigerLTStd-Roman-300.vlw"を入れる。

particleTime.pde

// Mover --------------- int moversNum = 7500; ArrayList<Mover> movers;

// Time ---------------- PGraphics graTime; PFont font;

// Timer --------------- int timer = 3000; int counter = 0;

// Dot ----------------- PImage dot;

void setup() { size( 1200, 800 ); noStroke(); colorMode( RGB, 1.0 );

dot = loadImage( "dot.png" ); font = loadFont( "data/FrutigerLTStd-Roman-300.vlw" );

graTime = createGraphics(width, height ); drawGraTime();

movers = new ArrayList<Mover>(); for ( int i=0; i<moversNum; i++) { movers.add( new Mover(dot) ); } }

void draw() {

background( 0 );

drawGraTime();

checkTimer();

for ( Mover m : movers ) { m.update(); m.display(); }

}

// Time =============================== void drawGraTime() { String strMin = formatNum( minute(), 2 ); String strHou = formatNum( hour(), 2 ); graTime.beginDraw(); graTime.colorMode( RGB, 1.0 );

graTime.background( 0.0 ); graTime.fill( 1.0 ); graTime.textFont(font, 300 ); //graTime.textSize( 300 ); graTime.text( strHou+":"+ strMin, 190, 500); graTime.endDraw();

//image( graTime, 0, 0 ); }

void checkTimer() {

int current = millis(); if ( current - counter > timer ) {

counter = current;

for ( Mover m : movers ) {

float x; float y; color c; do { x = random(width); y = random(height); c = graTime.get( (int)x, (int)y); } while ( c < color(0.99) );

m.setTarget( new PVector( x, y ) ); } } }

Mover.pde

class Mover {

PVector pos; PVector vel; PVector acc;

PVector targetPos;

float size = 1; PImage dot;

Mover( PImage _dot ) { dot = _dot; targetPos = new PVector(width/2, height/2); pos = new PVector( random(width), random(height) ); vel = new PVector(0, 0); acc = new PVector(0, 0); }

void update() {

PVector vec = new PVector( targetPos.x - pos.x, targetPos.y - pos.y ); vec.normalize(); vec.mult( 0.5 ); acc.add(vec);

vel.add( acc ); vel.mult(0.94); pos.add( vel );

acc.mult(0); }

void display() { image( dot, pos.x, pos.y, size, size); }

void setTarget( PVector _targetPos) { targetPos = _targetPos; float power = 25; acc = new PVector( random(-power, power), random(-power, power) ); } }

util.pde

String formatNum( int _num, int _digit ) { String strNum = str(_num); while ( strNum.length() < _digit ) { strNum = "0" + strNum; } return strNum; }

0 notes