Block Producer Candidate Report #9 - May 16, 2018
EOS BLOCK PRODUCER CANDIDATE REPORT #9, May 16 2018
Due to the increasing volume of BP candidacy announcements we are now helping everyone transition towards the new EOS Go Block Producer Research Site, where BP candidates maintain their own landing page with a quick overview and links to their information. All candidates are also presented on a large map and can update their own page of information any time. See this section of the site to learn more.
EOS Go will offer one more BPC Report before launch: Report #10, posted Wednesday May 30th.
We’d like to thank the EOS community for their patience during the unforeseen release delay of Report #9.
BPC Reports #9 and #10 include the additional and final 2 Checkmark Criteria:
“Block Producer Roadmap” and “Stance on Dividends.”
Please follow this link for full details about the final checkmark criteria.
BP Candidates - if you have not already submitted information to qualify for the final Checkmarks #7 and 8, please do so before the final BPC Report #10 submission cut-off time: Tuesday May 29 at 2359 UTC.
THIS WEEK’S NEWS and NOTES
- Report #9 includes 41 new block producer candidates.
- Reports #9 & #10 only contain links to the BP Research Portal to help streamline research for community members. Block Producer Candidates - please continue updating your page on the BP Research Portal with all links and info so the community can get a quick overview of your candidacy, and dive in for a deeper look through your links.
Check-Mark Criteria Charts
The list is ordered by check-mark totals, highest to lowest, with each sub-section randomized within the high-low overall sort. (E.g., all BPCs with total of say, 5 checkmarks, will be randomly-listed within their peer grouping.)
This report was updated May 20 to include two missed candidates and some additional check-marks for others.
(List with links to BP Candidate Research Site Pages is below this chart.)
Summary Charts
Checkmark Criteria Summary This chart summarizes how many BPCs out of the current total group size meet each of EOS Go’s six community-reviewed “Checkmark Criteria” and two additional Checkmark Criteria, #7 and 8, for basic transparency and informativeness:
BPCs By Country
BPCs By Region
The Original Six Check Mark Criteria
1) PUBLIC PRESENCE: A public website URL and at least one social media account.
2) ID ON STEEMIT: Links to the following ID information, all posted to the Steem blockchain (either in one post or multiple):
- Official block producer candidate name.
- Location of company headquarters.
- Expected location of servers.
- Type of servers (cloud, bare metal, etc).
- Current employee list and pictures of at least 67% of staff.
- Relevant background qualifications for at least 67% of staff.
3) TECH SPECS: Estimate of technical specifications and total expenditure for resources by June 3, 2018 - posted to Steem blockchain. Check mark given for any estimate, modesty encouraged by permanent Steem record. Quality and accuracy of effort will be judged by the EOS community.
4) SCALING PLAN: Estimated scaling plan for hardware after June 3, 2018 - posted to Steem blockchain. Rough outlines receive a check mark, open review gauges the effort.
5) COMMUNITY BENEFIT: Community benefit project outline, only for projects expected to be public by June 3, 2018 - posted to Steem blockchain.
6) TELEGRAM+TESTNET: Listing of Telegram and Test-net node names for community testnet participation.
The Two Additional Check Mark Criteria, #7 and 8:
Please see details at this link: 2 new Checkmark Criteria
Below is a list of all candidates with their website and Steem verification posts.
Report Summary Stats
Summary||
-
Report period # 9 Report timestamp 2018-05-16, 01:27:54 UTC New BPCs added this period 44 Total active BPCs 150 Unlisted BPCs (not included in reports) 6
The following list of current Block Producer Candidates (BPCs) is sorted by the same methods as the graphical list above. Information presented in the BP Research Site was submitted directly by BPCs and has been minimally checked by EOS Go volunteers but not verified for completeness or accuracy.
Randomized List of Block Producer Candidates with URLs meeting basic minimum standards
BP Candidate Organization|URLs
-
Genesis Mining - Iceland BP Research Site LibertyBlock - Bhutan BP Research Site BP Squared - Puerto Rico BP Research Site EOS JRR - Switzerland BP Research Site eosDAC - Anguilla BP Research Site OracleChain - China BP Research Site Crypto Lions - Ukraine BP Research Site EOS Emerge - Poland BP Research Site HelloEOS - China BP Research Site Worbli - USA BP Research Site GEOS - Singapore BP Research Site Wancloud - China BP Research Site EOSChain - China BP Research Site EosLaoMao - Japan BP Research Site Block Matrix - England BP Research Site EOS Silicon Valley - USA BP Research Site EOS India (Indian Eagle) - India EOS Galaxy - China BP Research Site EOSCUBE - China BP Research Site EOS UK - England BP Research Site EOSREAL - Singapore BP Research Site eosbidu - China BP Research Site BitcoinGod - USA BP Research Site EOSRaychain - Hong Kong BP Research Site EOS BlockSmith - USA BP Research Site Aloha EOS - USA BP Research Site EOS Argentina - Argentina BP Research Site Bitfinex - British Virgin Islands BP Research Site Blockgenic - USA BP Research Site EOS Authority - England BP Research Site EOS Vikings - Norway BP Research Site EOSeco - China BP Research Site EOS Amsterdam - Netherlands BP Research Site Active EOS - USA BP Research Site EOSSw Eden - Sweden BP Research Site JEDA - Japan BP Research Site EOSMX - Mexico BP Research Site EOSMatrix - Seychelles BP Research Site EOS New York - USA BP Research Site EOSBIXIN - China BP Research Site EOS BPAC - India BP Research Site EOS Canada - Canada BP Research Site EOSUNION - China BP Research Site EOSYS - South Korea BP Research Site EOS Asia - Hong Kong BP Research Site EOS CSX - USA Infinity Stones - USA BP Research Site EOSvillage - China BP Research Site TOP.ONE - British Virgin Islands BP Research Site EOS Bepal - China EOS Van - Canada BP Research Site EOS Plane - China EOSWenzhou - China BP Research Site EOSVibes - Netherlands BP Research Site TOKENIKA - Poland BP Research Site EOS Nation - Canada BP Research Site TChain EOS - USA BP Research Site BuildTeam - Malta BP Research Site BlockCC - Hong Kong BP Research Site BlockPro.One - India BP Research Site EOS Singapore - Singapore BP Research Site ShEOS - Spain BP Research Site Free Space - USA BP Research Site EOS Costa Rica - Costa Rica BP Research Site EOSeoul - South Korea BP Research Site EOS PH - Phillipines BP Research Site EOS.CYBEX - China BP Research Site LiquidEOS - Israel BP Research Site Eos.Store - China BP Research Site EOSphere - Australia BP Research Site EOSOCAL - USA BP Research Site EOSLove - USA BP Research Site Huobi Pool - China BP Research Site The Swarm - USA BP Research Site eosio.sg - Singapore BP Research Site eos.cafe - Canada BP Research Site EOS.MediShares - Singapore BP Research Site EOS Cannon - China BP Research Site EOSKh - Cambodia BP Research Site MeetOne - Singapore BP Research Site EOS the World LLC - Puerto Rico BP Research Site EOS Palliums - China BP Research Site EOS Land - Canada BP Research Site Starteos - China BP Research Site SaltBlock - USA BP Research Site EOS Tribe - USA BP Research Site EOS Gravity - China BP Research Site EOS Dublin - Ireland BP Research Site DAO.EOS - Hong Kong BP Research Site BitSpace - Norway BP Research Site eosONO - China BP Research Site SuperONE - China BP Research Site EOS42.io - England BP Research Site EOSMetal - Iceland BP Research Site GenerEOS Sydney - Australia BP Research Site EOS Rio - Brazil BP Research Site EOS WTZ - China BP Research Site EOS90s - China BP Research Site Distributed Fund - EOS BP - Russia BP Research Site HKEOS - Hong Kong BP Research Site BlockchainLab EOS - Ukraine BP Research Site EOS Games - China BP Research Site EOS Titan - Bulgaria BP Research Site EOZNz - New Zealand eosmeso - Guatemala BP Research Site Greymass - USA BP Research Site FishOne - China ChainRift LLC - Slovenia eospace - China BP Research Site EOSHCC - Singapore BP Research Site AcroEOS - South Korea BP Research Site UnlimitedEOS - Japan BP Research Site EOS Beijing - China BP Research Site ChainPool - China BP Research Site EOS Arabia - Saudi Arabia BP Research Site EOS - NL - Netherlands BP Research Site EOS Shenzhen - China BP Research Site EOSTEA - China BP Research Site eos.fish - China EosGen - Hong Kong BP Research Site RoelandP - Netherlands BP Research Site CIGEOS - China EOS NodeOne - South Korea EOSNAIROBI - Kenya BP Research Site 91EOS - China BP Research Site Whateos - China BP Research Site EOS.Hedging - Hong Kong EOS Root - China BP Research Site EOSGeek - China BP Research Site Cypherglass - USA BP Research Site EOS Green - Poland BP Research Site webvr - Singapore BP Research Site Attic Lab - Ukraine BP Research Site EOS Detroit - USA BP Research Site EOSAntPool - China EOSDR.io - Dominican Republic BP Research Site EOS Pool - USA BP Research Site EOSZON - Russia BP Research Site EOS College - USA ViaBTC - China EOS Germany - Germany BP Node - Canada Aimi Blockchain Technology. Co - Singapore BP Research Site Advanced Engineering Solutions LLC - Russia EOSBROS - Switzerland BP Research Site EOS BLOCK PRODUCERS DUBAI - UAE Colorado Blockchain Capital - USA Eos Oklahoma - USA Fire Cloud Blockchain Inc - China INBlockchain - China
FOR BP CANDIDATES:
Please continue to update your landing page on the BP Research Portal at https://bp.eosgo.io - the community should be able to easily get an overview of your candidacy and quickly find your most important links to learn more.
BPCs without at least 1 URL showing clear evidence of Block Producer candidacy are no longer listed. To have your BP Candidacy re-listed please submit a valid URL or Steemit post with information about your candidacy to<EMAIL_ADDRESS>OR through the original BP Candidate form.
**New candidates - to be included in report #10 releasing May 30, please fill out this form or email<EMAIL_ADDRESS>Process Notes
-
BPC information is accepted on a rolling basis. The current on-line form for submitting data is this GoogleForm. (NOTE, this link may change over time, be sure you are looking at the most-recent version of this Weekly BPC Report to get the correct link.)
-
BPC list randomization is performed with the Shuffle tool in the AbleBits Power Tools plugin for GoogleSheets.
-
Why Steem? In the interest of fairness and transparency we request all BPCs to post information on a blockchain-backed platform where content cannot be silently altered or removed. This provides short- and long-term assurance to all parties – other block producer candidates, EOS token holders, and the interested general public.
-
As of BPC Report #8 EOS Go stopped including SHA256 checksums for in-line SteemIt images after it became clear that such protocol offers no reliable assurance of data integrity. SHA256 checksums do continue to apply to the privately-archived snapshots of raw BPC form submissions, as detailed below.
-
EOS Go archives a local snapshot of the raw BPC form submission data (a .CSV-format spreadsheet) at the close of each weekly period. The .CSV snapshot will be archived for at least 2 years and its SHA256 checksum is posted in the report. In the event of a serious discrepancy or conflict relating to the BPC registration process a trusted 3rd party (such as an arbitrator) could examine one or more weekly data snapshots to verify their chronological integrity.
ORIGINAL
Raw form data .CSV snapshot as of the closing timestamp of Reporting Period #9:
File name: 2018-05-16_01_27_54UTC_Snapshot_Block_Producer_Candidate_Form_Raw_Responses.csv
SHA256 checksum: cdc4eb8d7400f5ef22492927f44173c23e4537311e9fbc7ab19950286312b9a9
Links to Previous BPC Reports
Block Producer Candidacy Report #8 Block Producer Candidacy Report #7 Block Producer Candidacy Report #6 Block Producer Candidacy Report #5 Block Producer Candidacy Report #4 Block Producer Candidacy Report #3 Block Producer Candidacy Report #2 Block Producer Candidacy Report #1
Addenda & Corrections
Any changes after initial publication of this report will be logged here.
Contact Information
If you have questions or comments about EOS Go’s Weekly Block Producer Candidate Report please reach out to us at:
https://forums.eosgo.io - Forums http://t.me/EOSProject - Live Chat<EMAIL_ADDRESS>- Email


Click to Pause
and then:
select
z
in the
Call Stack
look for
x
under the
f
group in the
Scopes
section


{{$ctrl.action}} Issued Part
On Site Visit / {{$ctrl.action}} Issued Part
Parts Details
Part Code
Part Name
Available Qty
Request Qty
Total Issued Qty
Issued Qty
{{parts.code}}
{{parts.name}}
{{parts.total_avail_qty}}
{{parts.total_request_qty}}
{{parts.total_issued_qty}}


| fkUtilities reference pages |
s=STRUCT_SETDIFF(s1,s2) s=STRUCT_SETDIFF(s1,s2,1)
s=STRUCT_SETDIFF(s1,s2) returns the fields in s1 that are not present in s2. The function recurses if the same field is present in both structs and the two fields themselves are structs.
s=STRUCT_SETDIFF(s1,s2,1) if a field is a struct in s1, but not a struct in s2 (or vice versa), then the fields are considered to be different and thus the field IS returned in the result.
| nearestpoint | Toolbox page | parseArgs |


STAT(1) User Commands STAT(1) NAME stat - display file or file system status SYNOPSIS stat [OPTION]... FILE... DESCRIPTION Display file or file system status. -L, --dereference follow links -f, --file-system display file system status instead of file status -c --format=FORMAT use the specified FORMAT instead of the default; output a newline after each use of FORMAT --printf=FORMAT like --format, but interpret backslash escapes, and do not output a mandatory trailing newline. If you want a newline, include \n in FORMAT -t, --terse print the information in terse form --help display this help and exit --version output version information and exit The valid format sequences for files (without --file-system): %a Access rights in octal %A Access rights in human readable form %b Number of blocks allocated (see %B) %B The size in bytes of each block reported by %b %C SELinux security context string %d Device number in decimal %D Device number in hex %f Raw mode in hex %F File type %g Group ID of owner %G Group name of owner %h Number of hard links %i Inode number %m Mount point %n File name %N Quoted file name with dereference if symbolic link %o I/O block size %s Total size, in bytes %t Major device type in hex %T Minor device type in hex %u User ID of owner %U User name of owner %w Time of file birth, human-readable; - if unknown %W Time of file birth, seconds since Epoch; 0 if unknown %x Time of last access, human-readable %X Time of last access, seconds since Epoch %y Time of last modification, human-readable %Y Time of last modification, seconds since Epoch %z Time of last change, human-readable %Z Time of last change, seconds since Epoch Valid format sequences for file systems: %a Free blocks available to non-superuser %b Total data blocks in file system %c Total file nodes in file system %d Free file nodes in file system %f Free blocks in file system %i File System ID in hex %l Maximum length of filenames %n File name %s Block size (for faster transfers) %S Fundamental block size (for block counts) %t Type in hex %T Type in human readable form NOTE: your shell may have its own version of stat, which usually super‐ sedes the version described here. Please refer to your shell's documen‐ tation for details about the options it supports. AUTHOR Written by Michael Meskes. REPORTING BUGS Report stat bugs to<EMAIL_ADDRESS>GNU coreutils home page: <http://www.gnu.org/software/coreutils/> General help using GNU software: <http://www.gnu.org/gethelp/> Report stat translation bugs to <http://translationproject.org/team/> COPYRIGHT Copyright © 2011 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>. This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. SEE ALSO stat(2) The full documentation for stat is maintained as a Texinfo manual. If the info and stat programs are properly installed at your site, the com‐ mand info coreutils 'stat invocation' should give you access to the complete manual. GNU coreutils 8.12.197-032bb September 2011 STAT(1)


| Name: mr. anirudh | Reg No: 9-8smmhc18 |
|---|---|
| Age / Sex:31/m | Contact No:8095922693 |
| Marital Status:single. | Date:27/8/18 |
| Occupation:bank manager. Qual: mba. Bcom. | Dr. |
Address:native of Orissa-berampur. In blore sicne -12 years. |
DIAGNOSIS- |
Went for a random check as grandparents have it runs in family and his mom found out tht after he goes to washroom ants were ther. So thts wen he noticed this trouble. 2 years back.
Started allo rx from last year only.
From his side no complaints are .
Aspiring for growth so was concerned at tht time and wasn’t happening. Its jus been 5 months back wer he is in a better position.
Because of shift timings the food habits are very irregular.
Past h/o:
Had rhinitis mayb around 15-16 years. 3 yrs back took mediciation fr it and now he is fine with it (homoe)
Family h/o:
mPgf:expired 2 yrs back at the age of 77yrs. dm.htn
mom 53 yrs: thyroid dysfunction
aunt 56 yrs: asthma
one younger sis – 2 yrs younger to him.
Personal h/o:
veg. by preference . never had it from childhood. Had vomiting after eating egg in childhood.
Fruits eats less. Drinks juice. Doc told not to eat after dm.
Likes spicy. Use to have sweets and chocolates. Drinks lot of soft drinks but now stopped. Only bcoz of sugar he stopped it 3 yrs back.
Watr; a lt. prefer chilled water … now taking mixed water but prefers it.
Sweat : ns.
Sleep: due to shift erratic. Dnt feel refreshed.
Dreams: ns
Happiest life: chance to travel abroad 10 yrs back ny usa.
Saddest life:
Hobbies: music and news channel , go out with frns.
Love dogs but parents don’t agree. Says wen I move out I will go and have a dog.
Choosy about friends/ 10 max..
Mix of follower and leader.
Close to mom. Prefer family over friends.
Like chess. Table tennis. Use to like cricket. But now due to age and group no scope fr it.
Fav color : shades of blue. Sky blue. Use to like black.
Likes travelling. Plays games wen depressed or listens to music.
Likes cold weather more.
Fav food – pannier items.
Rx:
Staphysagria 1m/ nat carb1m – 4-4-4-4.
Pl qid.
Rub 15 – 1 dose night b.food.


Prepros App Options
General
Less
Scss
Sass
Stylus
Jade
Haml
Coffee
Markdown
Css Folder
Javascripts Folder
Html File Extension
Enable Desktop Notifications
Auto Compile
Line numbers
Compress Css
Auto Compile
Line numbers
Use Compass
Output Style
Compressed
Nested
Expanded
Auto Compile
Line numbers
Use Compass
Output Style
Compressed
Nested
Expanded
Auto Compile
Line numbers
Compress Css
Use Nib
Auto Compile
Github Flavoured
Sanitize Output
Auto Compile
Uglify
Auto Compile
Pretty Output
Auto Compile
Double quotes
Output Format
Xhtml
Html5
Output Style
Indented
Ugly
Done


Shakhtar’s Taison banned after being sent off for racism reaction
Taison was shown the red card for an offensive gesture made towards Dynamo Kiev fans earlier this month.
Shakhtar Donetsk captain Taison has been banned for one match after he was sent off for reacting to alleged racism.
Earlier this month, the Brazil international made an offensive gesture towards Dynamo Kiev fans and then kicked the ball into their section of the stand before the referee led all the players off in the 77th minute.
Video footage shows Taison and Brazilian team-mate Dentinho leaving the pitch in tears after both had seemingly been targeted, while they were consoled by several Dynamo players.
Taison was shown the red card by the referee immediately after the match – played at Shakhtar’s temporary home at the OSK Metalist stadium in Kharkiv – had resumed.
“We are very disappointed by the decision of the Ukrainian FA to hand Taison a one-match ban,” said world players’ union Fifpro on Thursday.
“Sanctioning a victim of racial abuse is beyond comprehension and it plays into the hands of those who promote this kind of disgraceful behaviour.”
The Ukrainian Association of Football fined Dynamo Kiev £16,000 and ordered them to play one match behind closed doors. The club will also be on probation for the remainder of the season.


Please login to write a review of Safari1.
0500
HAVE YOU SEEN SAFARI1 BEFORE?
Please login to write a review.


I had an idea for a long time of creating a digital virtual space of my own. One which would incorporate a digital library where I could store anything I'd want in case I was keen on revisitng it. If one were to imagine this, you could think of a cyberpunkish thing-o or, say, any form of a modern-day library but all in a 3D format.
I did not quite manage to reach this point yet and I feel this would be incredibly cumbersome to work with. But as a placeholder I managed to create something else that would be much more flexible as I thought. I mean, I already had the digital infrastructure in place and fluency in a pretty cool framework and lots of data stored on a few websites, so I all I had to do is just fill in the blanks and decide what I actually loved that I'd like to perhaps store and share with the world?
A-ha but one may wonder what was deeper in my idea behind this? Well, at somestage in 2020 I discovered to my amaze that, I might not actually be as cultured as I once had thought. I mean, to think of it, while I was actually working and studying towards being a VFX Artist, I realised that I was quite some length behind some folks in many ways that I didn't really think was as deep as it was. Once I managed to catch up in many vectors, I decided that, it's worth actually putting together the library after all, which was fairly manual and quite tiring as a thing but now that I look back, it's kind of worth it as I can easily share this, very easily iterate upon this and view virtually on any device on most of which it works quite great.
I mean, think about it: what's your favorite movie? Book? What did you learn of cool recently that you'd like to play but you're most certain to forget? Sure you could use imdb n' stuff to bookmark everything but you know what, there's nothing like a bookshelf and one certainly start to appreciate one, once gone to a bookstore or a library. And having a digital one, set for the new world? That you can just click something that catches your eye, with a graphic you can pick and inspect more on professional online knowledge bases about what it is and where you can experience it? I just had to execute this.
And the 3D version? You know, never say never, just need to get to a certain point of excelence in the 3D world so I end up happy with it :)
Oh and the key thing?
The over 1200 Movies, 270 TV Shows and 350 Video Games Experienced and rated on Filmweb :) :) :)
In a way, it's a continuation of my capstone research project, which considered a hollistic personal hub consisting of all your digitally recorded activities with the aim of providing suggestions to embetter your life. I guess I skewed towards a more manual format, I suppose a marriage of whatever gets spewed out from the data structure bubbles and what I actually think can be achieved here. Perhaps I should create one for music as well? It'd be more of a nostalgia thing and I'd need to flex my programming muscles for real this time...


CL-STORE
A Common Lisp Serialization Package
Documentation
Basic details can be found in the
README
file.
Texinfo Manual
List of
Changes
When things break (or don't work as expected)
Try a
mailing list
Drop
me
a line


Do you want to set a default scorer to use on all future cases you create? Good thing we've got your back!
Lock down a system default scorer to be used.
No scorers to show!


Too few people here. Taxi, to the airport!
Entity-oriented queries is a possible denomination for those queries which revolve around entities. This means queries whose expected result is an entity or a list of entities, or queries that contain entity mentions. Within entity-oriented queries, we are interested in entity-bearing queries, i.e., those that typically consist of (one of the names of) an entity and possibly additional words that refine the intent behind the query. This part made of complementary context terms is referred to as the refiner of the query. Examples of these queries are “the rock movies” and “london book a hotel.”
An envisaged search engine would identify the intent behind such an entity-oriented query and present a result object according to the nature of the intent. For example, a user might ask for the population of the city of Stavanger, say, by querying “stavanger population.” The engine would recognize the population-related intent as a property that can be retrieved from the corresponding entry for Stavanger in a knowledge base of reference. The result might then boil down to a simple entity card for the city, that in particular displays an entry with the number of its population, as taken from the KB. This case is similar to the population field in the entity card for Oslo shown when querying “oslo” in Google, card that we observed in a previous post.
In another scenario, the user instead issues “taxi to stavanger airport.” Here, we would instead aim for recognizing that the intent for the Stavanger Airport behind the refiner “taxi to” rather deals with performing a transaction and booking a taxi. A possible result format, illustrated in the following figure, allows the user to provide details of her travel, such as her position and desired time, and displays a button to order a taxi.
In our work, we aim to understand entity-related search intents by studying those query refiners. What do entity-oriented queries ask for, and how can they be fulfilled?
We collect refiners for a set of prominent entities, and aggregate them across entity types to obtain type-level query patterns. For example, by representing with [airport] any entity of the type airport, we are interested in the intent behind “taxi to” in the type-level query pattern “taxi to [airport]”. We work with a representative sample of 50 entity types from Freebase type system. By analyzing an annotated collection of entity-bearing queries, aggregated by entity types, we obtain a clearer understanding of what entity-oriented queries ask for.
In particular, we make observations regarding which searches can be fulfilled by looking up direct answers from a knowledge base (e.g., when seeking the population of a city), and which would require to interact with external services (such as booking a taxi). We then need a suitable scheme to classify the entity intents. After a close inspection of the type-level refiners, we define the following scheme of intent categories. These categories are focused on how (and from which type of source) the information need can be fulfilled.
Intent categorization scheme
- Property: The refiner is about getting a specific entity property or attribute that can be looked up in a knowledge base. For example, "children" in the query "angelina jolie children" or "opening times" in "at&t stadium opening times." The criterion does not require the refiner to exist as a property in an actual knowledge base, but rather its existence to be reasonable.
- Website: The refiner looks to reach a specific website or application. For example, "twitter" in the query "karpathy twitter."
- Service: The refiner expresses the need to interact with a service, possibly by redirecting to an external site or app. For example, "menu" in the query "keens steakhouse menu" would indicate the need to access to an external site for reading the restaurant's menu. As another example, "new album" in "eric clapton new album" looks for a service to read about, or listen to, or buy the new album. The interaction would possibly involve further parameters, like 'from' and 'to' values for "ticket price" in the query "jpass bullet train ticket price."
- Other: None of the previous ones is applicable. For example, "india" in the query "microsoft india" merely serves to disambiguate the company office from other locations.
Understanding entity-oriented search intents
We annotate each of the type-level query patterns in the collection with one of these four intent categories, and obtain a distribution of entity intent categories per type. From the average proportions in these distributions, we observe that a 54.06% of unique entity-oriented queries are to be fulfilled by interacting with some external service or app, meanwhile, 28.6% look for direct answers from a knowledge base. Further, 5.34% of the type-level refiners represent an attempt to reach a website, while 12.08% of them do not fit into any of the previous three categories.
The entity types with the largest proportion of service intents are netflix genre
(with refiners like “videos,” “live”), election
(“map,” “polls”), football match
(“video,” “highlights”), and music_album
.
The property intent category covers refiners that are of a more static nature, e.g., chemical compound
(with refiners like “structural formula,” “molecular weight”), political party
(“slogan,” “president”), star
(“type of star,” “temperature”), or tower
(“hours,” “height”); only the first one is a very prominent type.
Most of the entity types exhibit a non-empty proportion of website intents. Among all the types, this category exceeds the average proportion, e.g., for organization
, business operation
, hotel
and blogger
. The most frequent website refiners in the whole corpus are “wikipedia,” “twitter,” “facebook,” and “youtube.”
A marginal proportion of refiners are classified as having the other intent. A few exceptional cases with large proportions of other intents are, e.g., business operation
and house
(where the refiner is usually a location), or basketball player
(for which many refiners refer mostly to an NBA franchise, e.g., “lakers”).
If you are interested in more of this, please read Sections 5.1 to 5.3 of my thesis Task-Based Support in Search Engines, for technical details of the problem, the terminology, the methodology, and the experimental results and analysis.


NeoLoad
| Min | Avg | Max | Med | Avg-90% | Std Dev |
|---|---|---|---|---|---|
| NeoLoad/User Load | |||||
| 0 | 8.38 | 11 | 9 | 8.86 | 2.89 |
| NeoLoad/Throughput | |||||
| 0 | 0.001 | 0.004 | 0 | 0.001 | 0.001 |
| NeoLoad/Alerts | |||||
| 0 | 0 | 0 | - | - | - |
| NeoLoad/Critical Alerts | |||||
| 0 | 0 | 0 | - | - | - |
| NeoLoad/Warning Alerts | |||||
| 0 | 0 | 0 | - | - | - |
LG localhost
| Min | Avg | Max | Med | Avg-90% | Std Dev |
|---|---|---|---|---|---|
| LG localhost/CPU | |||||
| 0 | 5.01 | 22 | 5 | 4.69 | 4.56 |
| LG localhost/Memory | |||||
| 12 | 14.4 | 18 | 13 | 14.5 | 2.18 |
| LG localhost/Throughput | |||||
| 0 | 0.001 | 0.004 | 0 | 0.001 | 0.001 |
| LG localhost/User Load | |||||
| 0 | 8.38 | 11 | 9 | 8.86 | 2.89 |
| LG localhost/Network/Segments sent/sec. | |||||
| 0 | 172.7 | 2,210 | 0 | 119.6 | 433.8 |
| LG localhost/Network/Segments retransmitted/sec. | |||||
| 0 | 0 | 0 | 0 | 0 | 0 |
| LG localhost/Network/net4 (Microsoft ISATAP Adapter)/Megabits received/sec. | |||||
| 0 | 0 | 0 | - | - | - |
| LG localhost/Network/net4 (Microsoft ISATAP Adapter)/Megabits sent/sec. | |||||
| 0 | 0 | 0 | - | - | - |
| LG localhost/Network/eth3 (Intel(R) 82579LM Gigabit Network Connection)/Megabits received/sec. | |||||
| 0 | 0.043 | 1.13 | 0.003 | 0.022 | 0.164 |
| LG localhost/Network/eth3 (Intel(R) 82579LM Gigabit Network Connection)/Megabits sent/sec. | |||||
| 0 | 0.025 | 0.744 | 0 | 0.022 | 0.093 |
| LG localhost/Population1/User Load | |||||
| 0 | 8.38 | 11 | 9 | 8.86 | 2.89 |
| LG localhost/Population1/VirtualUser/User Load | |||||
| 0 | 8.38 | 11 | 9 | 8.86 | 2.89 |


{% extends 'moj_template/base.html' %} {% load staticfiles %} {% block content %}
There is nothing here yet.
That's because we need your help to build it. We can't expect to anticipate all possible uses and needs around our data, so we won't start building anything before we find that it's needed.
If you have needs around this data, around easier ways to access it in order to build useful services, let us know. Go to the download page, leave your details, and possibly explore the dataset. We'll then get back to you.


SVM in regression.
SVM in regression.Try to find the hyperplane f(x) = w.x+b as minimize
(where if , else ) (and is the number of training examples) (the size of is here 2*)
("eps" is eps_regression in the code)
(in fact, we use a kernel kernel instead of a dot product)
The coefficients are given by C_ when you call the constructor. If this one is NULL, all C_j will have the value given by the "C" option. (The size of C_ must be 2*data->n_real_examples)
Options:
"C" real trade off between the weight decay and the error [100] "eps regression" real size of the error tube [0.7] "cache size" real cache size (in Mo) [50]
Alphabetic index HTML hierarchy of classes or Java


Hacktop Blog
July 27, 2020
Hello, this page is a long time coming.
I've had jrcharney.hacktop.io/hacktop
in embosed label tape on the back of the lapdock part of the hacktop for years. Only now have I finally got around to making this page to talk about my device.
The great thing about is is that upgrades are easy. You don't like how the OS is? Swap out a microSD card and start over. Depending on where you get microSD cards, you can get them for cheap. MicroCenter is my goto place for that. Recently got a 128GB Class 10 microSD card for about $12. (Mind you it is their store brand. But their brand is pretty good.)
One thing I would recommend is have another Raspberry Pi around in the event things get dicey. There's no way you can fix things with a Windows machine since Windows will only recognize the boot partition but not the partition with your data on it. So have another Pi on hand with a USB micro SD card reader when the you know what hits the fan.
Speaking of fans, I would recommend using the Pimoroni fan shim if you are using a Pi4. The fan is very quiet.
In order for the Pi to not shut down when you close the lid, it is recommended that it run on a separate power supply. When I first started this project, I was a fan of the Anker power supplies, but for some reason just about every company has it set up that you can't charge the powerbank while using it. Something about wear and tear or something, I forget. I'll post something about why that is later.
Right now, I just want to make this page. Photos will ensue.
What I will say is that I upgraded to a 4GB Pi 4 model, which is probably the second most powerful Pi next to the 8GB which wasn't available at the store.
The other change, I am using Manjaro Linux ARM 20.06 at the time of this writing. I wanted to switch to an Arch-based Linux because so much awesome stuff I saw on Reddit's UNIX Porn forum (/r/unixporn). I'm a big fan of pixel art and demoscene, but I think a lot of people develop their art on computers that could render a Pixar film when a big part of demoscene is minimalism.
Starting next week, I will be participating in LaunchCode (St. Louis) Liftoff. So for the next 8 weeks or so, stay tuned to this website (not this webpage necessarily) for project news.
While this page is about the hacktop, sometimes I won't use the lapdock and run my Pi headless over SSH and VNC. More so since Manjaro has an emphasis on being used with end-user devices (clients like personal computers) rather than servers. But I won't let that define how I use linux. Useing it headless will also allow me to simply share my Linux machine in VNC or SSH in Zoom Screen shares rather than the hassle of swapping between windows programs. So network your computers together. Eventually, we'll find a way to have people work together on the same machine as linux machines can do that.
That's all the news for now. Big things are coming here! Stay tuned!


|
| int | enet_address_get_host (const ENetAddress *address, char *hostName, size_t nameLength) |
| | Attempts to do a reverse lookup of the host field in the address parameter. More...
|
| |
| int | enet_address_get_host_ip (const ENetAddress *address, char *hostName, size_t nameLength) |
| | Gives the printable form of the IP address specified in the address parameter. More...
|
| |
| int | enet_address_set_host (ENetAddress *address, const char *hostName) |
| | Attempts to resolve the host named by the parameter hostName and sets the host field in the address parameter if successful. More...
|
| |
| int | enet_address_set_host_ip (ENetAddress *address, const char *hostName) |
| | Attempts to parse the printable form of the IP address in the parameter hostName and sets the host field in the address parameter if successful. More...
|
| |
| enet_uint32 | enet_crc32 (const ENetBuffer *, size_t) |
| |
| void | enet_deinitialize (void) |
| | Shuts down ENet globally. More...
|
| |
| void | enet_host_bandwidth_limit (ENetHost *, enet_uint32, enet_uint32) |
| | Adjusts the bandwidth limits of a host. More...
|
| |
| void | enet_host_bandwidth_throttle (ENetHost *) |
| |
| void | enet_host_broadcast (ENetHost *, enet_uint8, ENetPacket *) |
| | Queues a packet to be sent to all peers associated with the host. More...
|
| |
| void | enet_host_channel_limit (ENetHost *, size_t) |
| | Limits the maximum allowed channels of future incoming connections. More...
|
| |
| int | enet_host_check_events (ENetHost *, ENetEvent *) |
| | Checks for any queued events on the host and dispatches one if available. More...
|
| |
| void | enet_host_compress (ENetHost *, const ENetCompressor *) |
| | Sets the packet compressor the host should use to compress and decompress packets. More...
|
| |
| int | enet_host_compress_with_range_coder (ENetHost *host) |
| | Sets the packet compressor the host should use to the default range coder. More...
|
| |
| ENetPeer * | enet_host_connect (ENetHost *, const ENetAddress *, size_t, enet_uint32) |
| | Initiates a connection to a foreign host. More...
|
| |
| ENetHost * | enet_host_create (const ENetAddress *, size_t, size_t, enet_uint32, enet_uint32) |
| | Creates a host for communicating to peers. More...
|
| |
| void | enet_host_destroy (ENetHost *) |
| | Destroys the host and all resources associated with it. More...
|
| |
| void | enet_host_flush (ENetHost *) |
| | Sends any queued packets on the host specified to its designated peers. More...
|
| |
| enet_uint32 | enet_host_random_seed (void) |
| |
| int | enet_host_service (ENetHost *, ENetEvent *, enet_uint32) |
| | Waits for events on the host specified and shuttles packets between the host and its peers. More...
|
| |
| int | enet_initialize (void) |
| | Initializes ENet globally. More...
|
| |
| int | enet_initialize_with_callbacks (ENetVersion version, const ENetCallbacks *inits) |
| | Initializes ENet globally and supplies user-overridden callbacks. More...
|
| |
| ENetVersion | enet_linked_version (void) |
| | Gives the linked version of the ENet library. More...
|
| |
| ENetPacket * | enet_packet_create (const void *, size_t, enet_uint32) |
| | Creates a packet that may be sent to a peer. More...
|
| |
| void | enet_packet_destroy (ENetPacket *) |
| | Destroys the packet and deallocates its data. More...
|
| |
| int | enet_packet_resize (ENetPacket *, size_t) |
| | Attempts to resize the data in the packet to length specified in the dataLength parameter. More...
|
| |
| void | enet_peer_disconnect (ENetPeer *, enet_uint32) |
| | Request a disconnection from a peer. More...
|
| |
| void | enet_peer_disconnect_later (ENetPeer *, enet_uint32) |
| | Request a disconnection from a peer, but only after all queued outgoing packets are sent. More...
|
| |
| void | enet_peer_disconnect_now (ENetPeer *, enet_uint32) |
| | Force an immediate disconnection from a peer. More...
|
| |
| void | enet_peer_dispatch_incoming_reliable_commands (ENetPeer *, ENetChannel *) |
| |
| void | enet_peer_dispatch_incoming_unreliable_commands (ENetPeer *, ENetChannel *) |
| |
| void | enet_peer_on_connect (ENetPeer *) |
| |
| void | enet_peer_on_disconnect (ENetPeer *) |
| |
| void | enet_peer_ping (ENetPeer *) |
| | Sends a ping request to a peer. More...
|
| |
| void | enet_peer_ping_interval (ENetPeer *, enet_uint32) |
| | Sets the interval at which pings will be sent to a peer. More...
|
| |
| ENetAcknowledgement * | enet_peer_queue_acknowledgement (ENetPeer *, const ENetProtocol *, enet_uint16) |
| |
| ENetIncomingCommand * | enet_peer_queue_incoming_command (ENetPeer *, const ENetProtocol *, const void *, size_t, enet_uint32, enet_uint32) |
| |
| ENetOutgoingCommand * | enet_peer_queue_outgoing_command (ENetPeer *, const ENetProtocol *, ENetPacket *, enet_uint32, enet_uint16) |
| |
| ENetPacket * | enet_peer_receive (ENetPeer *, enet_uint8 *channelID) |
| | Attempts to dequeue any incoming queued packet. More...
|
| |
| void | enet_peer_reset (ENetPeer *) |
| | Forcefully disconnects a peer. More...
|
| |
| void | enet_peer_reset_queues (ENetPeer *) |
| |
| int | enet_peer_send (ENetPeer *, enet_uint8, ENetPacket *) |
| | Queues a packet to be sent. More...
|
| |
| void | enet_peer_setup_outgoing_command (ENetPeer *, ENetOutgoingCommand *) |
| |
| int | enet_peer_throttle (ENetPeer *, enet_uint32) |
| |
| void | enet_peer_throttle_configure (ENetPeer *, enet_uint32, enet_uint32, enet_uint32) |
| | Configures throttle parameter for a peer. More...
|
| |
| void | enet_peer_timeout (ENetPeer *, enet_uint32, enet_uint32, enet_uint32) |
| | Sets the timeout parameters for a peer. More...
|
| |
| size_t | enet_protocol_command_size (enet_uint8) |
| |
| size_t | enet_range_coder_compress (void *, const ENetBuffer *, size_t, size_t, enet_uint8 *, size_t) |
| |
| void * | enet_range_coder_create (void) |
| |
| size_t | enet_range_coder_decompress (void *, const enet_uint8 *, size_t, enet_uint8 *, size_t) |
| |
| void | enet_range_coder_destroy (void *) |
| |
| ENetSocket | enet_socket_accept (ENetSocket, ENetAddress *) |
| |
| int | enet_socket_bind (ENetSocket, const ENetAddress *) |
| |
| int | enet_socket_connect (ENetSocket, const ENetAddress *) |
| |
| ENetSocket | enet_socket_create (ENetSocketType) |
| |
| void | enet_socket_destroy (ENetSocket) |
| |
| int | enet_socket_get_address (ENetSocket, ENetAddress *) |
| |
| int | enet_socket_get_option (ENetSocket, ENetSocketOption, int *) |
| |
| int | enet_socket_listen (ENetSocket, int) |
| |
| int | enet_socket_receive (ENetSocket, ENetAddress *, ENetBuffer *, size_t) |
| |
| int | enet_socket_send (ENetSocket, const ENetAddress *, const ENetBuffer *, size_t) |
| |
| int | enet_socket_set_option (ENetSocket, ENetSocketOption, int) |
| |
| int | enet_socket_shutdown (ENetSocket, ENetSocketShutdown) |
| |
| int | enet_socket_wait (ENetSocket, enet_uint32 *, enet_uint32) |
| |
| int | enet_socketset_select (ENetSocket, ENetSocketSet *, ENetSocketSet *, enet_uint32) |
| |
| enet_uint32 | enet_time_get (void) |
| | Returns the wall-time in milliseconds. More...
|
| |
| void | enet_time_set (enet_uint32) |
| | Sets the current wall-time in milliseconds. More...
|
| |


| 1 | /* | |
| 2 | * Licensed to the Apache Software Foundation (ASF) under one or more | |
| 3 | * contributor license agreements. See the NOTICE file distributed with | |
| 4 | * this work for additional information regarding copyright ownership. | |
| 5 | * The ASF licenses this file to You under the Apache License, Version 2.0 | |
| 6 | * (the "License"); you may not use this file except in compliance with | |
| 7 | * the License. You may obtain a copy of the License at | |
| 8 | * | |
| 9 | * http://www.apache.org/licenses/LICENSE-2.0 | |
| 10 | * | |
| 11 | * Unless required by applicable law or agreed to in writing, software | |
| 12 | * distributed under the License is distributed on an "AS IS" BASIS, | |
| 13 | * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. | |
| 14 | * See the License for the specific language governing permissions and | |
| 15 | * limitations under the License. | |
| 16 | */ | |
| 17 | ||
| 18 | package org.apache.commons.math3.analysis.solvers; | |
| 19 | ||
| 20 | import org.apache.commons.math3.analysis.polynomials.PolynomialFunction; | |
| 21 | ||
| 22 | /** | |
| 23 | * Base class for solvers. | |
| 24 | * | |
| 25 | * @since 3.0 | |
| 26 | * @version $Id: AbstractPolynomialSolver.java 1364387 2012-07-22 18:14:11Z tn $ | |
| 27 | */ | |
| 28 | public abstract class AbstractPolynomialSolver | |
| 29 | extends BaseAbstractUnivariateSolver<PolynomialFunction> | |
| 30 | implements PolynomialSolver { | |
| 31 | /** Function. */ | |
| 32 | private PolynomialFunction polynomialFunction; | |
| 33 | ||
| 34 | /** | |
| 35 | * Construct a solver with given absolute accuracy. | |
| 36 | * | |
| 37 | * @param absoluteAccuracy Maximum absolute error. | |
| 38 | */ | |
| 39 | protected AbstractPolynomialSolver(final double absoluteAccuracy) { | |
| 40 | super(absoluteAccuracy); | |
| 41 | } | |
| 42 | /** | |
| 43 | * Construct a solver with given accuracies. | |
| 44 | * | |
| 45 | * @param relativeAccuracy Maximum relative error. | |
| 46 | * @param absoluteAccuracy Maximum absolute error. | |
| 47 | */ | |
| 48 | protected AbstractPolynomialSolver(final double relativeAccuracy, | |
| 49 | final double absoluteAccuracy) { | |
| 50 | super(relativeAccuracy, absoluteAccuracy); | |
| 51 | } | |
| 52 | /** | |
| 53 | * Construct a solver with given accuracies. | |
| 54 | * | |
| 55 | * @param relativeAccuracy Maximum relative error. | |
| 56 | * @param absoluteAccuracy Maximum absolute error. | |
| 57 | * @param functionValueAccuracy Maximum function value error. | |
| 58 | */ | |
| 59 | protected AbstractPolynomialSolver(final double relativeAccuracy, | |
| 60 | final double absoluteAccuracy, | |
| 61 | final double functionValueAccuracy) { | |
| 62 | super(relativeAccuracy, absoluteAccuracy, functionValueAccuracy); | |
| 63 | } | |
| 64 | ||
| 65 | /** | |
| 66 | * {@inheritDoc} | |
| 67 | */ | |
| 68 | @Override | |
| 69 | protected void setup(int maxEval, PolynomialFunction f, | |
| 70 | double min, double max, double startValue) { | |
| 71 | 1 | super.setup(maxEval, f, min, max, startValue); |
| 72 | polynomialFunction = f; | |
| 73 | } | |
| 74 | ||
| 75 | /** | |
| 76 | * @return the coefficients of the polynomial function. | |
| 77 | */ | |
| 78 | protected double[] getCoefficients() { | |
| 79 | 1 | return polynomialFunction.getCoefficients(); |
| 80 | } | |
| 81 | } | |
Mutations | ||
| 71 |
removed call to org/apache/commons/math3/analysis/solvers/BaseAbstractUnivariateSolver::setup : KILLED -> org.apache.commons.math3.analysis.solvers.LaguerreSolverTest.testParameters(org.apache.commons.math3.analysis.solvers.LaguerreSolverTest) |
|
| 79 |
mutated return of Object value for org/apache/commons/math3/analysis/solvers/AbstractPolynomialSolver::getCoefficients to ( if (x != null) null else throw new RuntimeException ) : KILLED -> org.apache.commons.math3.analysis.solvers.LaguerreSolverTest.testQuadraticFunction(org.apache.commons.math3.analysis.solvers.LaguerreSolverTest) |


JS Calendar
Sunday
Monday
Tuesday
Wednesday
Thursday
Friday
Saturday
No events has been added.
evento 1
evento 2
evento 3


Email<EMAIL_ADDRESS>GitHub: https://github.com/andrewcauyeung
Stony Brook University Class of 2019


[viewBag] title = "DEPARTMENT \"INFORMATICS\"" ==
|
111700, Chirchik, st. Amir Temur, house 104. +99897-707-53-93 |
Head of Department Ahmedjonov Dilmurod Gulomovich |
The department was founded in January 2019 and today the department of "Informatics" is part of the faculty of "Exact Sciences" and is graduating in the following direction:
Baccalaureate - “Pedagogical Education” (training profile: methods of teaching informatics).
Today, a unique multi-disciplinary team has formed at the department, in which specialists, scientists and practitioners of various scientific fields work, such as information technology, computer linguistics, information security, programming, computer graphics, the use of information technologies in national and agricultural sectors and others.
Leading teachers of the department:
Leaders and leading specialists of organizations and enterprises whose activities are related to the direction of the main professional educational programs being implemented are involved in the training sessions. These are specialists in the field of teacher education, information security, web design and computer graphics, as well as programming.
To intensify the educational process, the teaching staff of the department uses modern teaching methods, uses multimedia tools, excursions to leading higher educational institutions in this area and information and communication technologies for conducting classes.
Of great importance for consolidating theoretical material and mastering the skills of a teacher are the practices conducted in secondary schools.
Creative contacts connect the department with the leading universities and research institutes of the Academy of Sciences of the Republic of Uzbekistan: scientific research institute of irrigation and water problems, National University of Uzbekistan named after Mirzo Ulugbek, Tashkent State Pedagogical University named after Nizami, Tashkent University of Information Technologies, Tashkent Institute of Irrigation and Agricultural Mechanization Engineers and secondary schools.
The department carries out international cooperation in the implementation of joint projects, scientific internships and the organization of educational practices with several European universities:
The department conducts research in the following priority areas:
Teachers of the department regularly participate in interregional and international seminars and conferences.
List of directions and training levels
Higher Education - Undergraduate
|
Code |
Direction |
Training Profiles |
|
5110700 |
methods of teaching informatics
|
Informatiks
Learning Languages: Uzbek, Russian |
Faculty
|
Akhmedzhonov Dilmurod Gulomovich |
Doctor of Technical Sciences, Head of Department |
|
Gulboev Nematulla Abdukarimovich |
Candidate of Technical Sciences, Associate Professor |
|
Zhuraeva Nilufar Vayitovna |
Candidate of Technical Sciences, Associate Professor |
|
Gaynazarov Sulton Mamanazarovich |
Candidate of Physical and Mathematical Sciences, Associate Professor |
|
Mamarazhabov Mirsalim Elmirzaevich |
Сandidate of pedagogical sciences, associate professor |
|
Sultonov Bozorboy |
Candidate of Technical Sciences, Associate Professor |
|
Makhmudova Dilfuza Melievna |
Doctor of Philosophy in Pedagogical Sciences (PhD) |
|
Karpova Olga Vladimirovna |
Candidate of Physical and Mathematical Sciences, Associate Professor |
|
Khurramov Anvar Zhumanazarovich |
Doctor of Philosophy in Pedagogical Sciences (PhD) |
|
Boymurodov Adham Khushimkulovich |
Senior Lecturer |
|
Ismoilov Azamat Arslanboevich |
Senior Lecturer |
|
Duysenov Nurmakhambet Elamaovich |
Senior Lecturer |
|
Zhomirzaev Abdugofur Abdurahimovich |
Senior Lecturer |
|
Kamolov Eshmurod Rakhmonovich |
Senior lecturer |
|
Kholmetova Muhabbat Khudoynazarovna |
Teacher |
|
Yuldasheva Gulshad Tleuovna |
Teacher |
|
Akhmedov Bekzhan Askarovich |
Teacher |
|
Sultonov Ravshan Otonazarovich |
Teacher |
|
Kurolov Yuldosh Abdullaevich |
Teacher |
|
Rakhmonova Gulhayo Sayijon qizi |
Teacher |
|
Kudratilloev Navshod Abdulloevich |
Teacher |
|
Razhabov Oybek Tokaymurod ugli |
Teacher |
|
Rakhimov Sanzhar Muhammadovich |
Teacher |
|
|
|


In this chapter we explore advanced reactive stream processing, where application state is subject to live change based on events. By performing transformations and aggregations on events, we will see how to compute live statistics on what is happening in the larger 10k steps application. We will also see how event streams can impact real-time web applications by unifying Java and JavaScript code under the Vert.x event bus umbrella.
This chapter starts with advanced stream processing with RxJava operators and Vert.x clients. We then discuss the topic of real-time web applications connected over the event-bus, before finishing with techniques to properly deal with state (and especially the initial state) in a context of continuous events.
In previous chapters we have used RxJava operators to process events of all kinds: HTTP requests, AMQP messages and Kakfa records. RxJava is a versatile library for reactive programming, and it is especially well-suited for processing event streams with the Flowable type for back-pressured streams. Kafka provides a solid middleware for event streaming, while Vert.x provides a rich ecosystem of reactive clients to connect to other services, databases or messaging systems.
The event stats service is an event-driven reactive service that consumes Kafka records and produces some statistics as other Kafka records. We are going to see how we can use RxJava operators to efficiently address 3 common operations on event streams:
The daily.step.updates Kafka topic is populated with records sent from the activity service. The records contain 3 entries: the device identifier, a timestamp when the record was produced, and a number of steps.
Whenever a device update is processed by the activity service, it stores the update to a PostgreSQL database, then produces a Kafka record with the number of steps on the current day for the corresponding device. For instance when device abc receives an update of say, 300 steps recorded at 11:25, then it sends a Kafka record to daily.step.updates with the number of steps for the day corresponding to device abc.
The event stats service consumes these events to enrich them with user data, so other services can be updated in real-time about the number of steps recorded on the current day for any user. To do that we take the records from the daily.step.updates Kafka topic, and add the data from the user API: user name, email, city, and whether data shall be public. The enriched data is then sent as records to the event-stats.user-activity.updates topic.
This is an implementation technique for the content enricher messaging pattern in the seminal Enterprise Integration Patterns book [EIP].
The steps to enrich data are the following, as shown in figure 11.1.
For each incoming Kafka record:
event-stats.user-activity.updates
Gzxlz ctipo zng ticmom jr.Listing 11.1 shows the corresponding RxJava pipeline.
KafkaConsumer.<String, JsonObject>create(vertx, KafkaConfig.consumer("event-stats-user-activity-updates")) .subscribe("daily.step.updates") #1 .toFlowable() .flatMapSingle(this::addDeviceOwner) #2 .flatMapSingle(this::addOwnerData) #3 .flatMapCompletable(this::publishUserActivityUpdate) #4 .doOnError(err -> logger.error("Woops", err)) .retryWhen(this::retryLater) .subscribe();
The RxJava pipeline composes asynchronous operations with flatMapSingle and flatMapCompletable. This is because doing a HTTP request is a (single) result, while committing a Kafka record is an operation with not return value (hence completable). We also see the common error handling logic from earlier chapters with a delayed re-subscription. Listing 11.2 shows the implementation of method addDeviceOwner.
private Single<JsonObject> addDeviceOwner(KafkaConsumerRecord<String, JsonObject> record) { JsonObject data = record.value(); #1 return webClient .get(3000, "localhost", "/owns/" + data.getString("deviceId")) #2 .as(BodyCodec.jsonObject()) .rxSend() .map(HttpResponse::body) #3 .map(data::mergeIn); #4 }
This method makes a HTTP request whose result is a JSON object, and returns the merge of the source Kafka record JSON data with the request result data. Once this is done we know who the device of the record belongs to, so we can chain with another request to get the user data from the user profile API, as in listing 11.3.
This method follows the same pattern as addDeviceOwner, as it takes the result from the previous operation as a parameter, makes a HTTP request to the user profile API, then returns merged data. The last operation is that of method publishActivityUpdate, given in listing 11.4.
private CompletableSource publishUserActivityUpdate(JsonObject data) { return producer.rxWrite( #1 KafkaProducerRecord.create("event-stats.user-activity.updates", data.getString("username"), data)); }
The implementation is writing the Kafka record to the target event-stats.user-activity.updates topic.
The ingestion service receives the incoming device updates from HTTP and AMQP, then publishes them to the incoming.steps Kafka topic. The ingestion throughput is typical of a dashboard metric, where the value is frequently updated with the number of device updates ingested per second. This is a good indicator of the stress level on the larger application as every update triggers further events being processed by other micro-services.
To do so we need to listen for records on the incoming.steps topic, then aggregate records over a fixed time window, and count how many records have been received. This is illustrated in figure 11.2.
Listing 11.5 shows the RxJava pipeline for computing the throughput and publishing the results to the event-stats.throughput Kafka topic.
KafkaConsumer.<String, JsonObject>create(vertx, KafkaConfig.consumer("event-stats-throughput")) .subscribe("incoming.steps") #1 .toFlowable() .buffer(5, TimeUnit.SECONDS, RxHelper.scheduler(vertx)) #2 .flatMapCompletable(this::publishThroughput) #3 .doOnError(err -> logger.error("Woops", err)) .retryWhen(this::retryLater) .subscribe();
The buffer operator is one of the several aggregation operators that you can use in RxJava. It aggregates events for a time period, then passes the result as a List. You can see that we pass a Vert.x scheduler from the RxHelper class: this because buffer delays event processing and by default will call the next operators on a RxJava-specific thread. The Vert.x scheduler ensures that operators are instead called from the original Vert.x context so as to preserve the Vert.x threading model.
Once buffer has aggregated all Kafka records over the last 5 seconds, method publishThroughput computes and publishes the throughput as given in listing 11.6.
private CompletableSource publishThroughput(List<KafkaConsumerRecord<String, JsonObject>> records) { KafkaProducerRecord<String, JsonObject> record = KafkaProducerRecord.create("event-stats.throughput", new JsonObject() #1 .put("seconds", 5) .put("count", records.size()) .put("throughput", (((double) records.size()) / 5.0d))); #2 return producer.rxWrite(record); #3 }
Given the records list we can easily compute a throughput and publish a new record. We take care to indicate the number of records and time window size in seconds, so that event consumers have all information and not just the raw result.
Let us now see another form of data aggregation based on RxJava operators by computing per-city trends. More specifically we are interested in computing periodically how many steps have been recorded in each city on the current day. To do that we can re-use the events published to the event-stats.user-activity.updates Kafka topic by the very same event stats service, since they contain how many steps a user has recorded today along with other data, including the city.
We could reuse the buffer operator as in listing 11.5, and then iterate over the list of records. For each record we would update a hash table entry where the key would be the the city, and the value would be the number of steps. We would then publish an update for each city based on the values in the hash table.
We can however write a more idiomatic RxJava processing pipeline thanks to the groupBy operator, as shown in listing 11.7.
KafkaConsumer.<String, JsonObject>create(vertx, KafkaConfig.consumer("event-stats-city-trends")) .subscribe("event-stats.user-activity.updates") .toFlowable() .groupBy(this::city) #1 .flatMap(group -> group.buffer(5, TimeUnit.SECONDS, RxHelper.scheduler(vertx))) #2 .flatMapCompletable(this::publishCityTrendUpdate) #3 .doOnError(err -> logger.error("Woops", err)) .retryWhen(this::retryLater) .subscribe();
As events enter the pipeline, the groupBy operator dispatches them to groups based on the city values found in records (the discriminant). You can think of groupBy as the equivalent of GROUP BY in a SQL statement. The filtering function city is given in listing 11.8 and extracts the city value from the Kafka record.
private String city(KafkaConsumerRecord<String, JsonObject> record) { return record.value().getString("city"); }
The groupBy operator returns here a Flowable of GroupedFlowable of Kafka records. Each GroupedFlowable is a flowable that is dedicated to the grouped records of a city, as dispatched by groupBy using the city function. For each group the flatMap operator is then used to group event in time windows of 5 seconds, meaning that per-city steps are updated every 5 seconds. Finally the publishCityTrendUpdate method prepares a new record with updated stats for each city, as given in listing 11.9.
private CompletableSource publishCityTrendUpdate(List<KafkaConsumerRecord<String, JsonObject>> records) { if (records.size() > 0) { #1 String city = city(records.get(0)); #2 Long stepsCount = records.stream() .map(record -> record.value().getLong("stepsCount")) #3 .reduce(0L, Long::sum); #4 KafkaProducerRecord<String, JsonObject> record = KafkaProducerRecord.create("event-stats.city-trend.updates", city, new JsonObject() .put("timestamp", LocalDateTime.now().toString()) .put("seconds", 5) .put("city", city) .put("stepsCount", stepsCount) .put("updates", records.size())); return producer.rxWrite(record); #5 } else { return Completable.complete(); #6 } }
The publishCityTrendUpdate method receives a list of Kafka records for a given city and from a time window. We first have to check if there is any record, otherwise there is nothing to do. With records we can use Java streams to compute the sum with a reduce operator, then prepare a Kafka record with several entries: a timestamp, the time window duration in seconds, the city, how many steps have been recorded, and how many updates were observed during the time window. Once this is done we write the record to the event-stats.city-trend.updates Kafka topic.
Now that we’ve studied how to perform advanced event streaming processing with RxJava and Vert.x, let’s see how to propagate events to reactive web applications.
As specified in chapter 7, the dashboard web application consumes events from the stats service and displays:
This application is updated live as soon as new data is received, which makes for a nice case of end-to-end integration between backend services and web browsers. The application is a micro-service as illustrated in figure 11.4.
The dashboard service is made of 2 parts:
s Ptrk.k rcsieve yrrz:
Letâs start with the Kafka to event bus forwarding.
Both throughput and city trend updates are directly forwarded to the Vue.js application code. These are the records received on the event-stats.throughput and event-stats.city-trend.updates Kafka topics.
In DashboardWebAppVerticle we put in place the RxJava pipelines of listing 11.10.
KafkaConsumer.<String, JsonObject>create(vertx, KafkaConfig.consumerConfig("dashboard-webapp-throughput")) .subscribe("event-stats.throughput") #1 .toFlowable() .subscribe(record -> forwardKafkaRecord(record, "client.updates.throughput")); #2 KafkaConsumer.<String, JsonObject>create(vertx, KafkaConfig.consumerConfig("dashboard-webapp-city-trend")) .subscribe("event-stats.city-trend.updates") .toFlowable() .subscribe(record -> forwardKafkaRecord(record, "client.updates.city-trend"));
These 2 RxJava pipelines have no complicated logic, as they forward to the client.updates.throughput and client.updates.city-trend event bus destination. Listing 11.11 shows the implementation of method forwardKafkaRecord.
Since the Kafka record values are of type JsonObject, there is no data conversion to perform to publish them to the Vert.x event-bus.
The dashboard web application starts a HTTP server, as shown in the excerpt of listing 11.12.
Router router = Router.router(vertx); #1 // (...) RxJava pipelines to forward Kafka records router.get("/").handler(ctx -> ctx.reroute("/index.html")); #2 router.route().handler(StaticHandler.create("webroot/assets")); #3 // (...) Event bus bridge setup return vertx.createHttpServer() #4 .requestHandler(router) .rxListen(HTTP_PORT) .ignoreElement();
Listing 11.12 shows a HTTP server for serving static files. This is only an excerpt: we now need to see how the Vert.x event bus can be connected to web applications.
Vert.x offers an event bus integration using the SockJS library [SockJS]. SockJS is an emulation library for the WebSocket protocol [WebSocket], which allows browsers and servers to communicate in both directions on top of a persistent connection. The Vert.x core APIs offer support for WebSockets, but SockJS is interesting because not every browser in the market properly supports WebSockets, and some HTTP proxies / load balancers may reject WebSocket connections. SockJS uses WebSockets whenever it can, and fallbacks to other mechanisms such as long polling over HTTP, AJAX, JSONP or iframe.
The Vert.x web module offers a handler for SockJS connections that bridge the event bus, so the same programming model can be used from the server side (in Vert.x) and the client side (in JavaScript). Listing 11.13 shows how to configure it.
SockJSHandler sockJSHandler = SockJSHandler.create(vertx); #1 SockJSBridgeOptions bridgeOptions = new SockJSBridgeOptions() .addInboundPermitted(new PermittedOptions().setAddressRegex("client.updates.*")) #2 .addOutboundPermitted(new PermittedOptions().setAddressRegex("client.updates.*")); #3 sockJSHandler.bridge(bridgeOptions); #4 router.route("/eventbus/*").handler(sockJSHandler); #5
The bridge relies on a handler for SockJS client connections, with a set of permissions to allow only certain event bus destinations to be bridged. It is indeed important to limit the events that flow between the connected web applications and backend, both for security and performance reasons. In our case we decided that only the destinations starting with client.updates will be available.
On the web application side, the Vert.x project offers the vertx3-eventbus-client library which can be downloaded manually or using a tool like npm (the Node package manager). By using it we can connect to the event-bus, as outlined in listing 11.14.
import EventBus from 'vertx3-eventbus-client' #1 const eventBus = new EventBus("/eventbus") #2 eventBus.enableReconnect(true) #3 eventBus.onopen = () => { #4 eventBus.registerHandler("a.b.c", (err, message) => { #5 console.log(`Received: ${message.body}`) }) eventBus.publish("d.e.f", { #6 book: "Vert.x in Action", comment: "A great book!" }) }
The full code of the usage of the Vert.x event bus in a Vue.js component is in the part2-steps-challenge/dashboard-webapp/src/App.vue file of the source code repository. As we can see we have the same programming model in the JavaScript code: we can register event bus handlers and publish messages, just like we would to in Vert.x code.
The dashboard uses Vue.js, just like the public web application service that we saw earlier. The whole application essentially fits in the App.vue component which can be found in the project source code. The component data model is made of 3 entries, as found in listing 11.15.
data() { return { throughput: 0, #1 cityTrendData: {}, #2 publicRanking: [] #3 } },
These entries are being updated when events are received from the Vert.x event bus. To do that we use the Vue.js mounted life-cycle callback to connect to the event bus, then register handlers as in listing 11.16.
mounted() { eventBus.onopen = () => { eventBus.registerHandler("client.updates.throughput", (err, message) => { #1 this.throughput = message.body.throughput #2 }) eventBus.registerHandler("client.updates.city-trend", (err, message) => { const data = message.body data.moment = moment(data.timestamp) this.$set(this.cityTrendData, message.body.city, data) }) eventBus.registerHandler("client.updates.publicRanking", (err, message) => { this.publicRanking = message.body }) } },
The handlers update the model based on what is received from the event-bus. Since Vue.js is a reactive web application framework, the interface is updated when the data model changes. For instance when the value of throughput changes, then so does the value displayed by the HTML template of listing 11.17.
The city trends view rendering is a more elaborated template found in listing 11.18.

Trends

 City	 Steps

 <transition-group name="city-trends" tag="tbody">
 #1 {{ item.city }}	 #2  +{{ item.stepsCount }} #3  ({{ item.moment.format("ddd hh:mm:ss") }}) #4
 </transition-group>

The template iterates over all city data, and renders a table row for each. When a city has an update then the city row is updated thanks to the item.city binding which ensures uniqueness in the rows generated by the v-for loop. The transition-group tag is specific to Vue.js and is used for animation purposes: when the data order changes then row order changes with an animation. The loop iterates over cityTrendRanking, which is a computed property given in listing 11.19.
computed: { cityTrendRanking: function () { const values = Object.values(this.cityTrendData).slice(0) values.sort((a, b) => b.stepsCount - a.stepsCount) #1 return values } },
The cityTrendRanking computed property ranks entries by number of steps, so the dashboard shows cities with the most steps on top.
The throughput and city trends are updated every 5 seconds with updates coming from Kafka records, and whose JSON payloads are forwarded to the dashboard web application. This works well because updates are frequent and cover aggregated data, but as we are going to see now, things are more complicated for the users ranking.
The dashboard web applications shows a live ranking of users based on the number of steps they have made over the last 24 hours. Users can be ranked based on the updates produced by the event stats service, and sent to the event-stats.user-activity.updates Kafka topic.
Each record sent to event-stats.user-activity.updates contains the latest number of steps for a given user. The dashboard service can observe these events, update its state to keep track of how many steps a given user has done, and update the global ranking accordingly. The problem here is that we need some state to start with, because when it starts (or re-starts!) the dashboard service doesn’t know about the earlier updates.
We could configure the Kafka subscriber to restart from the beginning of the stream, but it could potentially span over several days or even weeks worth of data. So replaying all records when the dashboard service starts should in theory allow us to compute an accurate ranking, but this is a costly operation. Also we need to wait until all records have been processed before sending updates to the connected web applications, because this would induce a big traffic on the event-bus.
Another solution is to start by asking the activity service what the current day rankings are, which is a straightforward SQL query which is built-in the service. We call this the hydration phase. We can then update the ranking as we receive updates from the event-stats.user-activity.updates Kafka topic.
The dashboard service maintains a publicRanking field which is a map where keys are user names, and values are the latest user update entries as JSON data. When the service starts this collection is empty, so the first step is to fill it with data.
To do that the hydrate method is being called from the DashboardWebAppVerticle initialization method (rxStart), right after the Kafka consumers have been set as in listing 11.10. This method assembles ranking data by calling the the activity and user profile services, as given in listing 11.20.
WebClient webClient = WebClient.create(vertx); webClient .get(3001, "localhost", "/ranking-last-24-hours") #1 .as(BodyCodec.jsonArray()) .rxSend() .delay(5, TimeUnit.SECONDS, RxHelper.scheduler(vertx)) #2 .retry(5) #3 .map(HttpResponse::body) .flattenAsFlowable(Functions.identity()) .cast(JsonObject.class) .flatMapSingle(json -> whoOwnsDevice(webClient, json)) #4 .flatMapSingle(json -> fillWithUserProfile(webClient, json)) #5 .subscribe( this::hydrateEntryIfPublic, #6 err -> logger.error("Hydratation error", err), () -> logger.info("Hydratation completed"));
The implementation of method hydrate relies on getting a ranking of the devices over the last 24 hours. The service returns a JSON array ordered in the number of steps. We allow an arbitrary 5 seconds delay before doing the request, and allow 5 retries in case the activity service is not available. Once we have ranking data, then method whoOwnsDevice (listing 11.21) and fillWithUserProfile (listing 11.22) correlate a pedometer-centric data with a user. Finally method hydrateEntryIfPublic of listing 11.23 fills the publicRanking collection with data from users who opted to be in public rankings.
The whoOwnsDevice method performs a HTTP request to know who owns a device, then merges the resulting JSON data. At this point we need to fill the remaining user data, which is done via method fillWithUserProfile of listing 11.22.
The code is very similar to that of method whoOwnsDevice. Last but not least, method hydrateEntryIfPublic of listing 11.23 adds data to the publicRanking collection.
private void hydrateEntryIfPublic(JsonObject data) { if (data.getBoolean("makePublic")) { #1 data.put("timestamp", Instant.now().toString()); #2 publicRanking.put(data.getString("username"), data); #3 } }
Hydration is a process started asynchronously when the verticle starts and eventually the publicRanking collection holds accurate data. Note that at this stage we have not pushed any ranking data to the dashboard web application clients. Let us now see what happens next.
The user ranking is updated every 5 seconds: to do so we collect updates from users for 5 seconds, then update the public ranking data and push the result to the dashboard web application. We batch data over spans of 5 seconds to pace the dashboard refresh, but you can lower the time window or even get rid of it if you want a more lively dashboard. Listing 11.24 shows the RxJava pipeline to manage this process.
KafkaConsumer.<String, JsonObject>create(vertx, KafkaConfig.consumerConfig("dashboard-webapp-ranking")) .subscribe("event-stats.user-activity.updates") #1 .toFlowable() .filter(record -> record.value().getBoolean("makePublic")) #2 .buffer(5, TimeUnit.SECONDS, RxHelper.scheduler(vertx)) #3 .subscribe(this::updatePublicRanking); #4
The filter operator is used to keep only Kafka records where the user data is public, and the buffer operator makes 5 seconds windows of events. Listing 11.25 gives the implementation of method updatePublicRanking that processes these event batches.
The method describes the process in 3 steps:
Listing 11.26 provides the implementation of method copyBetterScores
.
private void copyBetterScores(List<KafkaConsumerRecord<String, JsonObject>> records) { for (KafkaConsumerRecord<String, JsonObject> record : records) { JsonObject json = record.value(); long stepsCount = json.getLong("stepsCount"); #1 JsonObject previousData = publicRanking.get(json.getString("username")); if (previousData == null || previousData.getLong("stepsCount") < stepsCount) { #2 publicRanking.put(json.getString("username"), json); } } }
The method updates the publicRanking collection when a collected entry has more steps count that the previous one, because there can potentially be a conflict between an undergoing hydration process and a user update. Listing 11.27 gives the pruneOldEntries method.
private void pruneOldEntries() { Instant now = Instant.now(); #1 Iterator<Map.Entry<String, JsonObject>> iterator = publicRanking.entrySet().iterator(); while (iterator.hasNext()) { #2 Map.Entry<String, JsonObject> entry = iterator.next(); Instant timestamp = Instant.parse(entry.getValue().getString("timestamp")); if (timestamp.until(now, ChronoUnit.DAYS) >= 1L) { #3 iterator.remove(); } } }
The method simply iterates over all ranking data entries in the publicRanking collection, and remove entries older than one day. The ranking is produced by the method computeRanking of listing 11.28.
private JsonArray computeRanking() { List<JsonObject> ranking = publicRanking.entrySet() .stream() .map(Map.Entry::getValue) #1 .sorted(this::compareStepsCountInReverseOrder) #2 .map(json -> new JsonObject() #3 .put("username", json.getString("username")) .put("stepsCount", json.getLong("stepsCount")) .put("city", json.getString("city"))) .collect(Collectors.toList()); return new JsonArray(ranking); #4 }
The method sorts public ranking data and produces a JSON array, where entries are ranked in reverse order (the first value is the user with most steps over the last 24 hours, etc). The compareStepsCountInReverseOrder method used to compare and sort entries is given in listing 11.29.
private int compareStepsCountInReverseOrder(JsonObject a, JsonObject b) { Long first = a.getLong("stepsCount"); Long second = b.getLong("stepsCount"); return second.compareTo(first); #1 }
The comparison returns -1 when b has less steps than a, 0 when they are equal, and 1 when b has more steps than a.
The Vue.js template for rendering the user ranking table is given in listing 11.30.

Public ranking (last 24 hours)

 Name	 From	 Steps

 <transition-group name="public-ranking" tag="tbody">
 #1 {{ item.username }}	 {{ item.city }}	 {{ item.stepsCount }}
 </transition-group>

The Vue.js code for the web application receives the ranking array over the event bus, and updates the publicRanking data entry. Whenever this happens then the display is updated to reflect the changes. Just like the city trends table, entries move using an animation as their order changes.
This concludes end-to-end stream processing, from Kafka records to reactive web applications. The next chapter focuses on resilience and fault-tolerance in reactive systems.
buffer
and groupBy
that can be composed to perform aggregate data processing.[SockJS] SockJS Project. SockJS. Retrieved February 2020. github.com/sockjs
[WebSocket] Internet Engineering Task Force (IETF). The WebSocket Protocol (RFC 6455). December 2011. tools.ietf.org/html/rfc6455


{{ entry.title }}
{{ entry.description }}
{{ entry.client.one().title }}
{#
# Entry template
# -------------------
#
# This template gets loaded whenever an entry’s URL is
# requested. That’s because the section’s Template setting is
# set to _section/entry”, the path to this template.
#
# When this template is loaded, it will already have an ‘entry’
# variable, set to the requested entry.
#
# See this entry for more details on how Craft routes requests:
# http://craftcms.com/docs/routing
#}
{% extends "_layouts/base" %}
{% import '_includes/elements' as elements %}
{% import '_includes/helpers' as helpers %}
{% block links %}
{{ parent() }}
{% endblock %}
{% block main %}
{# -- HERO -- #}
{% set image = entry.image.one() %}
{{ entry.client.one().title }}{{ entry.title }}
{{ entry.description }}
{{ item.client.one().title }}


Buoyancy Chart Data Explorer
- This visualization illustrates the popularity of terms that are relevant in your blog. Every Circle represents one term and the larger the circle is drawed the more important this term is for your blog. By hovering over the circle you can find out which term it describes.
- The color and the position of the cicles contains information about the popularity of the terms. Therefore a circle on the top represents a term with an increasing popularity whereas the terms for circles on the bottom have an decreasing popularity. The color indicates the current popularity: Green for highly widespreaded terms, red for slightly widespreaded terms and gray for averaged widespreaded terms.
- You can filter the terms using the checkboxes. A term is classified as popular, if it is already widespreaded (colored green) and it has a further increasing popularity (located at the top). The categories "decreasing" and "increasing" characterize terms that are currently only slightly widespreaded with an decreasing/increasing popularity.