| Property starting with A |
| Name |
Caption |
Description |
Type |
Mandatory |
Name (known in REST) |
Available since release |
Introduced by which team |
Introduced for which project |
Additional remarks |
|
AdditionalDateField01
|
Additional Date field 1
|
Additional Date field 1
|
Date
|
|
AdditionalDateField01
|
405
|
CMDM
|
EDI
|
|
|
AdditionalDateField02
|
Additional Date field 2
|
Additional Date field 2
|
Date
|
|
AdditionalDateField02
|
405
|
CMDM
|
EDI
|
|
|
AdditionalDateField03
|
Additional Date field 3
|
Additional Date field 3
|
Date
|
|
AdditionalDateField03
|
405
|
CMDM
|
EDI
|
|
|
AdditionalDateField04
|
Additional Date field 4
|
Additional Date field 4
|
Date
|
|
AdditionalDateField04
|
405
|
CMDM
|
EDI
|
|
|
AdditionalDateField05
|
Additional Date field 5
|
Additional Date field 5
|
Date
|
|
AdditionalDateField05
|
405
|
CMDM
|
EDI
|
|
|
AdditionalField01
|
Additional Text field 1
|
Additional Text field 1
|
String
|
|
AdditionalField01
|
405
|
CMDM
|
EDI
|
|
|
AdditionalField02
|
Additional Text field 2
|
Additional Text field 2
|
String
|
|
AdditionalField02
|
405
|
CMDM
|
EDI
|
|
|
AdditionalField03
|
Additional Text field 3
|
Additional Text field 3
|
String
|
|
AdditionalField03
|
405
|
CMDM
|
EDI
|
|
|
AdditionalField04
|
Additional Text field 4
|
Additional Text field 4
|
String
|
|
AdditionalField04
|
405
|
CMDM
|
EDI
|
|
|
AdditionalField05
|
Additional Text field 5
|
Additional Text field 5
|
String
|
|
AdditionalField05
|
405
|
CMDM
|
EDI
|
|
|
AdditionalField06
|
Additional Text field 6
|
Additional Text field 6
|
String
|
|
AdditionalField06
|
405
|
CMDM
|
EDI
|
|
|
AdditionalField07
|
Additional Text field 7
|
Additional Text field 7
|
String
|
|
AdditionalField07
|
405
|
CMDM
|
EDI
|
|
|
AdditionalField08
|
Additional Text field 8
|
Additional Text field 8
|
String
|
|
AdditionalField08
|
405
|
CMDM
|
EDI
|
|
|
AdditionalField09
|
Additional Text field 9
|
Additional Text field 9
|
String
|
|
AdditionalField09
|
405
|
CMDM
|
EDI
|
|
|
AdditionalField10
|
Additional Text field 10
|
Additional Text field 10
|
String
|
|
AdditionalField10
|
405
|
CMDM
|
EDI
|
|
|
AdditionalNumberField01
|
Additional Number field 1
|
Additional Number field 1
|
Number
|
|
AdditionalNumberField01
|
405
|
CMDM
|
EDI
|
|
|
AdditionalNumberField02
|
Additional Number field 2
|
Additional Number field 2
|
Number
|
|
AdditionalNumberField02
|
405
|
CMDM
|
EDI
|
|
|
AdditionalNumberField03
|
Additional Number field 3
|
Additional Number field 3
|
Number
|
|
AdditionalNumberField03
|
405
|
CMDM
|
EDI
|
|
|
AdditionalNumberField04
|
Additional Number field 4
|
Additional Number field 4
|
Number
|
|
AdditionalNumberField04
|
405
|
CMDM
|
EDI
|
|
|
AdditionalNumberField05
|
Additional Number field 5
|
Additional Number field 5
|
Number
|
|
AdditionalNumberField05
|
405
|
CMDM
|
EDI
|
|
|
AdditionalNumberField06
|
Additional Number field 6
|
Additional Number field 6
|
Number
|
|
AdditionalNumberField06
|
405
|
CMDM
|
EDI
|
|
|
AdditionalNumberField07
|
Additional Number field 7
|
Additional Number field 7
|
Number
|
|
AdditionalNumberField07
|
405
|
CMDM
|
EDI
|
|
|
AdditionalNumberField08
|
Additional Number field 8
|
Additional Number field 8
|
Number
|
|
AdditionalNumberField08
|
405
|
CMDM
|
EDI
|
|
|
AdditionalNumberField09
|
Additional Number field 9
|
Additional Number field 9
|
Number
|
|
AdditionalNumberField09
|
405
|
CMDM
|
EDI
|
|
|
AdditionalNumberField10
|
Additional Number field 10
|
Additional Number field 10
|
Number
|
|
AdditionalNumberField10
|
405
|
CMDM
|
EDI
|
|
|
AdditionalYesNoField01
|
Additional Yes/No field 1
|
Additional Yes/No field 1
|
Boolean
|
|
AdditionalYesNoField01
|
405
|
CMDM
|
EDI
|
|
|
AdditionalYesNoField02
|
Additional Yes/No field 2
|
Additional Yes/No field 2
|
Boolean
|
|
AdditionalYesNoField02
|
405
|
CMDM
|
EDI
|
|
|
AdditionalYesNoField03
|
Additional Yes/No field 3
|
Additional Yes/No field 3
|
Boolean
|
|
AdditionalYesNoField03
|
405
|
CMDM
|
EDI
|
|
|
AdditionalYesNoField04
|
Additional Yes/No field 4
|
Additional Yes/No field 4
|
Boolean
|
|
AdditionalYesNoField04
|
405
|
CMDM
|
EDI
|
|
|
AdditionalYesNoField05
|
Additional Yes/No field 5
|
Additional Yes/No field 5
|
Boolean
|
|
AdditionalYesNoField05
|
405
|
CMDM
|
EDI
|
|
|
ApplyLinkItem
|
ApplyLinkItem
|
ApplyLinkItem
|
Boolean
|
|
ApplyLinkItem
|
|
|
|
|
|
ApplyShippingCharges
|
Apply shipping charges
|
Apply shipping charges
|
Boolean
|
|
ApplyShippingCharges
|
|
|
|
|
| Property starting with C |
| Name |
Caption |
Description |
Type |
Mandatory |
Name (known in REST) |
Available since release |
Introduced by which team |
Introduced for which project |
Additional remarks |
|
Completed
|
Completed
|
Completed
|
Boolean
|
|
Completed
|
|
|
|
Read-Only (Since PU4...
|
|
CostCenter
|
Cost center
|
Cost center
|
String
|
|
CostCenter
|
|
|
|
|
|
CurrencyCode
|
Currency code
|
Currency code
|
String
|
|
CurrencyCode
|
|
|
|
|
|
CurrencyRate
|
XRate
|
XRate
|
String
|
|
CurrencyRate
|
|
|
|
|
| Property starting with D |
| Name |
Caption |
Description |
Type |
Mandatory |
Name (known in REST) |
Available since release |
Introduced by which team |
Introduced for which project |
Additional remarks |
|
DeletionReason
|
|
DeletionReason
|
String
|
|
DeletionReason
|
405
|
CBE
|
|
|
|
DeliveryDate
|
Delivery date
|
Delivery date
|
Date
|
|
DeliveryDate
|
|
|
|
|
|
DeliveryDebtor
|
Delivery debtor number
|
Delivery debtor number
|
String
|
|
DeliveryDebtor
|
|
|
|
|
|
DeliveryDebtorAddress1
|
Address line 1
|
Address line 1
|
String
|
|
DeliveryDebtorAddress1
|
|
|
|
|
|
DeliveryDebtorAddress2
|
Address line 2
|
Address line 2
|
String
|
|
DeliveryDebtorAddress2
|
|
|
|
|
|
DeliveryDebtorAddress3
|
Address line 3
|
Address line 3
|
String
|
|
DeliveryDebtorAddress3
|
|
|
|
|
|
DeliveryDebtorCity
|
City
|
City
|
String
|
|
DeliveryDebtorCity
|
|
|
|
|
|
DeliveryDebtorContactEmail
|
Delivery address contact person's email
|
Delivery address contact person's email
|
String
|
|
DeliveryDebtorContactEmail
|
|
|
|
|
|
DeliveryDebtorContactPerson
|
Contact
|
Contact
|
String
|
|
DeliveryDebtorContactPerson
|
|
|
|
|
|
DeliveryDebtorCountryCode
|
Country code
|
Country code
|
String
|
|
DeliveryDebtorCountryCode
|
|
|
|
|
|
DeliveryDebtorCounty
|
County
|
County
|
String
|
|
DeliveryDebtorCounty
|
|
|
|
|
|
DeliveryDebtorFax
|
Fax
|
Fax
|
String
|
|
DeliveryDebtorFax
|
|
|
|
|
|
DeliveryDebtorInitials
|
Initials
|
Initials
|
String
|
|
DeliveryDebtorInitials
|
|
|
|
|
|
DeliveryDebtorJobDescription
|
Job description
|
Job description
|
String
|
|
DeliveryDebtorJobDescription
|
|
|
|
|
|
DeliveryDebtorName
|
Delivery Debtor Name
|
Delivery Debtor Name
|
String
|
|
DeliveryDebtorName
|
|
|
|
|
|
DeliveryDebtorPhone
|
Phone
|
Phone
|
String
|
|
DeliveryDebtorPhone
|
|
|
|
|
|
DeliveryDebtorPostCode
|
Postcode
|
Postcode
|
String
|
|
DeliveryDebtorPostCode
|
|
|
|
|
|
DeliveryDebtorStateCode
|
State
|
State
|
String
|
|
DeliveryDebtorStateCode
|
|
|
|
|
|
DeliveryDebtorTitle
|
Title
|
Title
|
String
|
|
DeliveryDebtorTitle
|
|
|
|
|
|
Description1
|
Description 1
|
Description 1
|
String
|
|
Description1
|
|
|
|
|
|
Description2
|
Description 2
|
Description 2
|
String
|
|
Description2
|
|
|
|
|
|
Description3
|
Description 3
|
Description 3
|
String
|
|
Description3
|
|
|
|
|
|
DocumentID
|
Document ID
|
Document ID
|
GUID
|
|
DocumentID
|
|
|
|
|
| Property starting with E |
| Name |
Caption |
Description |
Type |
Mandatory |
Name (known in REST) |
Available since release |
Introduced by which team |
Introduced for which project |
Additional remarks |
|
ExtraItemDescription
|
Extra item description code
|
Extra item description code
|
String
|
|
ExtraItemDescription
|
|
|
|
|
| Property starting with F |
| Name |
Caption |
Description |
Type |
Mandatory |
Name (known in REST) |
Available since release |
Introduced by which team |
Introduced for which project |
Additional remarks |
|
FreeField1
|
Sales Order: free field 1
|
Sales Order: free field 1
|
String
|
|
FreeField1
|
|
|
|
|
|
FreeField2
|
Sales Order: free field 2
|
Sales Order: free field 2
|
String
|
|
FreeField2
|
|
|
|
|
|
FreeField3
|
Sales Order: free field 3
|
Sales Order: free field 3
|
String
|
|
FreeField3
|
|
|
|
|
|
FreeField4
|
Sales Order: free field 4
|
Sales Order: free field 4
|
Double
|
|
FreeField4
|
|
|
|
|
|
FreeField5
|
Sales Order: free field 5
|
Sales Order: free field 5
|
Double
|
|
FreeField5
|
|
|
|
|
| Property starting with G |
| Name |
Caption |
Description |
Type |
Mandatory |
Name (known in REST) |
Available since release |
Introduced by which team |
Introduced for which project |
Additional remarks |
|
GrossWeight
|
Gross weight
|
Gross weight
|
Double
|
|
GrossWeight
|
|
|
|
|
| Property starting with I |
| Name |
Caption |
Description |
Type |
Mandatory |
Name (known in REST) |
Available since release |
Introduced by which team |
Introduced for which project |
Additional remarks |
|
ID
|
ID
|
ID
|
Integer
|
|
ID
|
|
|
|
|
|
InvoiceCode
|
Invoice code
|
Invoice code
|
String
|
|
InvoiceCode
|
|
|
|
|
|
InvoiceDebtor
|
Invoice debtor
|
Invoice debtor
|
String
|
|
InvoiceDebtor
|
|
|
|
|
|
InvoiceDebtorAddress1
|
Address line 1
|
Address line 1
|
String
|
|
InvoiceDebtorAddress1
|
|
|
|
|
|
InvoiceDebtorAddress2
|
Address line 2
|
Address line 2
|
String
|
|
InvoiceDebtorAddress2
|
|
|
|
|
|
InvoiceDebtorAddress3
|
Address line 3
|
Address line 3
|
String
|
|
InvoiceDebtorAddress3
|
|
|
|
|
|
InvoiceDebtorCity
|
City
|
City
|
String
|
|
InvoiceDebtorCity
|
|
|
|
|
|
InvoiceDebtorContactEmail
|
Invoice address contact person's email
|
Invoice address contact person's email
|
String
|
|
InvoiceDebtorContactEmail
|
|
|
|
|
|
InvoiceDebtorContactPerson
|
Contact
|
Contact
|
String
|
|
InvoiceDebtorContactPerson
|
|
|
|
|
|
InvoiceDebtorCountryCode
|
Country code
|
Country code
|
String
|
|
InvoiceDebtorCountryCode
|
|
|
|
|
|
InvoiceDebtorFax
|
Fax
|
Fax
|
String
|
|
InvoiceDebtorFax
|
|
|
|
|
|
InvoiceDebtorInitials
|
Initials
|
Initials
|
String
|
|
InvoiceDebtorInitials
|
|
|
|
|
|
InvoiceDebtorJobDescription
|
Job description
|
Job description
|
String
|
|
InvoiceDebtorJobDescription
|
|
|
|
|
|
InvoiceDebtorName
|
Invoice Debtor Name
|
Invoice Debtor Name
|
String
|
|
InvoiceDebtorName
|
|
|
|
|
|
InvoiceDebtorPhone
|
Phone
|
Phone
|
String
|
|
InvoiceDebtorPhone
|
|
|
|
|
|
InvoiceDebtorPostCode
|
Postcode
|
Postcode
|
String
|
|
InvoiceDebtorPostCode
|
|
|
|
|
|
InvoiceDebtorStateCode
|
State
|
State
|
String
|
|
InvoiceDebtorStateCode
|
|
|
|
|
|
InvoiceDebtorTitle
|
Title
|
Title
|
String
|
|
InvoiceDebtorTitle
|
|
|
|
|
|
IsEDI
|
EDI
|
EDI
|
Boolean
|
|
IsEDI
|
|
|
|
|
|
IsForEditing
|
|
|
Boolean
|
|
IsForEditing
|
413
|
Log-Nxt
|
RD.GLB.16.US.SVCS.03
|
Set to True when try...
|
|
IsUseAdditionalFields
|
AdditionalFields
|
AdditionalFields
|
Boolean
|
|
IsUseAdditionalFields
|
405
|
CMDM
|
EDI
|
|
| Property starting with N |
| Name |
Caption |
Description |
Type |
Mandatory |
Name (known in REST) |
Available since release |
Introduced by which team |
Introduced for which project |
Additional remarks |
|
NetWeight
|
Net weight
|
Net weight
|
Double
|
|
NetWeight
|
|
|
|
|
| Property starting with O |
| Name |
Caption |
Description |
Type |
Mandatory |
Name (known in REST) |
Available since release |
Introduced by which team |
Introduced for which project |
Additional remarks |
|
OrderConfirmation
|
Print sales order confirmation
|
Print sales order confirmation
|
Boolean
|
|
OrderConfirmation
|
|
|
|
|
|
OrderDebtor
|
Debtor number
|
Debtor number
|
String
|
|
OrderDebtor
|
|
|
|
|
|
OrderDebtorAddress1
|
Address line 1
|
Address line 1
|
String
|
|
OrderDebtorAddress1
|
|
|
|
|
|
OrderDebtorAddress2
|
Address line 2
|
Address line 2
|
String
|
|
OrderDebtorAddress2
|
|
|
|
|
|
OrderDebtorAddress3
|
Address line 3
|
Address line 3
|
String
|
|
OrderDebtorAddress3
|
|
|
|
|
|
OrderDebtorCity
|
City
|
City
|
String
|
|
OrderDebtorCity
|
|
|
|
|
|
OrderDebtorContactEmail
|
Order address contact person's email
|
Order address contact person's email
|
String
|
|
OrderDebtorContactEmail
|
|
|
|
|
|
OrderDebtorContactPerson
|
Contact
|
Contact
|
String
|
|
OrderDebtorContactPerson
|
|
|
|
|
|
OrderDebtorCountryCode
|
Country code
|
Country code
|
String
|
|
OrderDebtorCountryCode
|
|
|
|
|
|
OrderDebtorFax
|
Fax
|
Fax
|
String
|
|
OrderDebtorFax
|
|
|
|
|
|
OrderDebtorInitials
|
Initials
|
Initials
|
String
|
|
OrderDebtorInitials
|
|
|
|
|
|
OrderDebtorJobDescription
|
Job description
|
Job description
|
String
|
|
OrderDebtorJobDescription
|
|
|
|
|
|
OrderDebtorName
|
Order Debtor Name
|
Order Debtor Name
|
String
|
|
OrderDebtorName
|
|
|
|
|
|
OrderDebtorPhone
|
Phone
|
Phone
|
String
|
|
OrderDebtorPhone
|
|
|
|
|
|
OrderDebtorPostCode
|
Postcode
|
Postcode
|
String
|
|
OrderDebtorPostCode
|
|
|
|
|
|
OrderDebtorStateCode
|
State
|
State
|
String
|
|
OrderDebtorStateCode
|
|
|
|
|
|
OrderDebtorTitle
|
Title
|
Title
|
String
|
|
OrderDebtorTitle
|
|
|
|
|
|
OrderLines
|
Order lines
|
Order lines
|
String
|
|
OrderLines
|
|
|
|
|
|
OurReference
|
Our reference
|
Our reference
|
String
|
|
OurReference
|
|
|
|
|
| Property starting with P |
| Name |
Caption |
Description |
Type |
Mandatory |
Name (known in REST) |
Available since release |
Introduced by which team |
Introduced for which project |
Additional remarks |
|
Packages
|
Packages
|
Packages
|
Number
|
|
Packages
|
|
|
|
|
|
ParentProject
|
ParentProject
|
ParentProject
|
String
|
|
ParentProject
|
|
|
|
|
|
PartialDelivery
|
Partial delivery allowed
|
Partial delivery allowed
|
Boolean
|
|
PartialDelivery
|
|
|
|
|
|
PaymentCondition
|
Payment condition
|
Payment condition
|
String
|
|
PaymentCondition
|
|
|
|
|
|
PaymentMethod
|
Payment method
|
Payment method
|
String
|
|
PaymentMethod
|
|
|
|
|
|
ProductLine
|
Product line
|
Origin of order created
|
String
|
|
ProductLine
|
|
|
|
|
|
Project
|
Project number
|
Project number
|
String
|
|
Project
|
|
|
|
|
| Property starting with R |
| Name |
Caption |
Description |
Type |
Mandatory |
Name (known in REST) |
Available since release |
Introduced by which team |
Introduced for which project |
Additional remarks |
|
Reference
|
Description
|
Description
|
String
|
|
Reference
|
|
|
|
|
|
Resource
|
Representative
|
Representative
|
Integer
|
|
Resource
|
|
|
|
|
|
Route
|
Route
|
Route
|
String
|
|
Route
|
|
|
|
|
| Property starting with S |
| Name |
Caption |
Description |
Type |
Mandatory |
Name (known in REST) |
Available since release |
Introduced by which team |
Introduced for which project |
Additional remarks |
|
SalesOrderDate
|
Sales order date
|
Sales order date
|
Date
|
|
SalesOrderDate
|
|
|
|
|
|
SalesOrderNumber
|
Sales order number
|
Sales order number
|
String
|
|
SalesOrderNumber
|
|
|
|
|
|
SelectionCode
|
Selection code
|
Selection code
|
String
|
|
SelectionCode
|
|
|
|
|
|
ShippingVia
|
Delivery method
|
Delivery method
|
String
|
|
ShippingVia
|
|
|
|
|
| Property starting with T |
| Name |
Caption |
Description |
Type |
Mandatory |
Name (known in REST) |
Available since release |
Introduced by which team |
Introduced for which project |
Additional remarks |
|
TotalAmount
|
Total amount
|
Total amount
|
Double
|
|
TotalAmount
|
|
|
|
Read-Only (Since PU4...
|
|
TotalAmountExcludingVAT
|
Total amount excluding VAT
|
Total amount excluding VAT
|
Double
|
|
TotalAmountExcludingVAT
|
|
|
|
Read-Only (Since PU4...
|
|
TotalVATAmount
|
Total VAT amount
|
Total VAT amount
|
Double
|
|
TotalVATAmount
|
|
|
|
Read-Only (Since PU4...
|
|
TransactionKey
|
Transaction key
|
Transaction key
|
GUID
|
|
TransactionKey
|
|
|
|
|
| Property starting with W |
| Name |
Caption |
Description |
Type |
Mandatory |
Name (known in REST) |
Available since release |
Introduced by which team |
Introduced for which project |
Additional remarks |
|
Warehouse
|
Warehouse
|
Warehouse
|
String
|
|
Warehouse
|
|
|
|
|
| Property starting with Y |
| Name |
Caption |
Description |
Type |
Mandatory |
Name (known in REST) |
Available since release |
Introduced by which team |
Introduced for which project |
Additional remarks |
|
YourReference
|
Your reference
|
Your reference
|
String
|
|
YourReference
|
|
|
|
|


Samsung Galaxy A71 leaks point to an Infinity-O display and quad-cameras
by Aakash JhaveriSamsung Galaxy A71 leaks point to an Infinity-O display and quad-cameras
Adding another one
(Image credit: Future)
The next wave of Samsung mid-rangers is upon us, which started with the Galaxy A51, and now it’s the Galaxy A71, which has been fully leaked and rendered.
Samsung brought a new naming scheme to its A series of mid-rangers, earlier this year. Their minor updates added an “s” suffix, and the bigger updates add a unit to the final name. The Samsung Galaxy A71 succeeds the A70 and the A70s, bringing a new design to the front and adding a camera to the rear.
These renders were shared by @OnLeaks, the reputed leakster, and give us a good idea about what to expect from the Samsung Galaxy A71. The most noticeable change comes with the display, as it sports a center-placed punch-hole Infinity-O display, making it one of the first devices after the Note10 to do so. Its predecessors had a conventional Infinity-U waterdrop notch.
This allows the display to attain a higher screen-to-body ratio. Coming in at 6.7-inches, the Galaxy A71 is one of the biggest displays on a non-flagship Samsung device. An optical in-display fingerprint scanner is also likely to be present here.
The other significant change comes with the cameras. The A70s brought a 64MP camera to Samsung’s mid-rangers, and the Galaxy A71 will add one more camera to the mix, bringing the total up to four. It will follow a design similar to the M30s with a big camera island, with the sensors arranged in an L-formation. The renders also suggest a camera bump.
The bottom has a loudspeaker grille, a USB Type-C port, and a headphone jack, while all the buttons are on the right side. Internal specifications powering the Samsung Galaxy A71 have not been detailed, but it should at least match the A70s, if not improve upon them.
For reference, the Galaxy A70s was powered by the Snapdragon 675 chipset with 6GB of RAM, housed a big 4,500mAh battery with support for 25W fast charging, and was one of the first Samsung smartphones with a 64MP primary camera, followed by an ultrawide and a depth sensor.
- Samsung Galaxy A70 review
- Samsung Galaxy A51 shown-off in new render images with four cameras
- Samsung Galaxy M30s review


If you’d like to support me developing this project you’re able to do so by donating on PayPal or if you have any special needs/ feature requests don’t hesitate to send me an email.
git clone https://github.com/vladotesanovic/angular2-express-starter
cd angular2-express-starter
# Install dependencies
npm install
# start server
npm run start
# Client url: http://localhost:4200
# Application ( epxress ) API: http://localhost:4300
Install Redux DevTools chrome extenstion:
https://chrome.google.com/webstore/detail/redux-devtools/lmhkpmbekcpmknklioeibfkpmmfibljd
npm run build
## Deploy dist folder to app server
Structure of dist folder:
/dist/server <-- expressjs
/dist/client <-- angular2
All html and css are from: http://www.w3schools.com/howto/


Govern Node Right.
Joyent recently announced that a new foundation will take control of Node. Important details about how the foundation will work have not yet been decided.
Now is the time to tell Joyent CEO Scott Hammond that you'd like io.js's open technical governance model to form the basis for the Node foundation's technical committee.
io.js's open goverance model ensures Node's future is not beholden to the needs of one or a few large companies, but rather determined by technical leaders who represent a spectrum of Node uses and users. If the Node foundation adopts it, the two projects can be merged into one again.
Tweet @Scott_Hammond: I'm a @nodejs user. I'd like to see the #nodejs foundation adopt @official_iojs technical governance model.
Not a Twitter user? Write in to Joyent on their Contact page.
This site is not officially affiliated with io.js. Why I made this site. More reasons why Node and io.js should merge.


If you are developing a web application or website that requires user to provide a location (address of their house, business, establishment etc) for visitors in Philippines, It might be useful for them to select from a list of Cities or Barangay instead of typing everything in a text field.
There is around approximately 42,000 plus barangays in the Philippines. Let alone the list of cities.
Storing this amount of data just to display this kind of dropdown is too much of hassle and load for most applications.
Not to mention, that you need to have the copy of this data in every database that needs this, there should be a better way of doing it...
I've developed a jQuery Plugin that allows you to turn any <select></select>
element into a dynamic one, so that its list of
<options></options>
is automatically populated by data via AJAX request.
The AJAX request is being initiated into a FREE REST API (that I've also developed)
which is pretty much responsible for returning the list of items depending on the filter and option you specified when invoking the plugin.
Here is a very simple demo of what the plugin can do. Below, you could see we have 4 dropdowns.
Each is being populated dynamically by the plugin, depending on the value of the dropdown above it
See LIVE DEMO
// attach handlers when user had selected an item in the dropdown
$('#region').on('change', function(){ // fill province dropdown });
$('#province').on('change', function(){ // fill cities dropdown });
$('#city').on('change', function(){ // fill barangay dropdown });
// call the plugin to those dropdowns with the proper location_type
$('#region').ph_locations({'location_type': 'regions'});
$('#province').ph_locations({'location_type': 'provinces'});
$('#city').ph_locations({'location_type': 'cities'});
$('#barangay').ph_locations({'location_type': 'barangays'});
// fill up the regions dropdown, so user can start "drilling down"
$('#region').ph_locations('fetch_list');
Note that this plugin doesn't requires you to install any backend script in your app. You can use it in any static website that have jQuery. Interested? head over to the Installation to start using it!
<script src="https://f001.backblazeb2.com/file/buonzz-assets/jquery.ph-locations-v1.0.0.js"></script>
jquery.ph-locations-v1.0.0.js
somewhere in your server and reference it.
create the markup
<select name="city" id="my-city-dropdown"></select>
$('#my-city-dropdown').ph_locations({'location_type': 'cities'});
$('#my-city-dropdown').ph_locations( 'fetch_list', [{"province_code": "1339"}]);
You can also check the source code of the demo to see how it is used.
You can show your support and appreciation by Buying me a coffee (I love coffee!).
The project is open-source and can be found in this GitHub repo. If you happen to find any bug or improvements that could be made to better cater to your project, feel free to open an issue


Basics
Hello, World!
The original purpose of "hello world", ever since the first C version was written, was to test the compiler and run an actual program.
// hello.rs fn main() { println!("Hello, World!"); }
$ rustc hello.rs
$ ./hello
Hello, World!
Rust is a curly-braces language with semicolons, C++-style comments and a main
function - so far, so familiar. The exclamation mark indicates that this is a
macro call.
For anybody else, it's probably "Great, now I have to remember when to say bang!". However, the compiler is unusually helpful; if you leave out that exclamation, you get:
error[E0425]: unresolved name `println`
--> hello2.rs:2:5
|
2 | println("Hello, World!");
| ^^^^^^^ did you mean the macro `println!`?
Learning a language means getting comfortable with its errors. Try to see the compiler as a strict but friendly helper rather than a computer shouting at you, because you are going to see a lot of red ink in the beginning. It's much better for the compiler to catch you out than for your program to blow up in front of actual humans.
The next step is to introduce a variable:
// let1.rs fn main() { let answer = 42; println!("Hello {}", answer); }
Spelling mistakes are compile errors, not runtime errors like with dynamic languages like Python or JavaScript. This will save you a lot of stress later! And if I wrote 'answr' instead of 'answer', the compiler is actually nice about it:
4 | println!("Hello {}", answr);
| ^^^^^ did you mean `answer`?
The println!
macro takes a format string
and some values; it's very similar to the formatting used by Python 3.
Another very useful macro is assert_eq!
. This is the workhorse of testing
in Rust; you assert that two things must be equal, and if not, panic.
// let2.rs fn main() { let answer = 42; assert_eq!(answer,42); }
Which won't produce any output. But change 42 to 40:
thread 'main' panicked at
'assertion failed: `(left == right)` (left: `42`, right: `40`)',
let2.rs:4
note: Run with `RUST_BACKTRACE=1` for a backtrace.
And that's our first runtime error in Rust.
Looping and Ifing
Anything interesting can be done more than once:
// for1.rs fn main() { for i in 0..5 { println!("Hello {}", i); } }
The range is not inclusive, so i
goes from 0 to 4. This is convenient in a
language which indexes things like arrays from 0.
And interesting things have to be done conditionally:
// for2.rs fn main() { for i in 0..5 { if i % 2 == 0 { println!("even {}", i); } else { println!("odd {}", i); } } }
even 0
odd 1
even 2
odd 3
even 4
i % 2
is zero if 2 can divide into i
cleanly; Rust uses C-style operators.
There are no brackets around the condition, just like in Go, but
you must use curly brackets around the block.
This does the same, written in a more interesting way:
// for3.rs fn main() { for i in 0..5 { let even_odd = if i % 2 == 0 {"even"} else {"odd"}; println!("{} {}", even_odd, i); } }
Traditionally, programming languages have statements (like if
) and
expressions (like 1+i
). In Rust, nearly everything has a value and can
be an expression. The seriously ugly C 'ternary operator' i % 2 == 0 ? "even" : "odd"
is not needed.
Note that there aren't any semi-colons in those blocks!
Adding Things Up
Computers are very good at arithmetic. Here is a first attempt at adding all the numbers from 0 to 4:
// add1.rs fn main() { let sum = 0; for i in 0..5 { sum += i; } println!("sum is {}", sum); }
But it fails to compile:
error[E0384]: re-assignment of immutable variable `sum`
--> add1.rs:5:9
3 | let sum = 0;
| --- first assignment to `sum`
4 | for i in 0..5 {
5 | sum += i;
| ^^^^^^^^ re-assignment of immutable variable
'Immutable'? A variable that cannot vary? let
variables by default can only
be assigned a value when declared. Adding the magic word mut
(please make
this variable mutable) does the trick:
// add2.rs fn main() { let mut sum = 0; for i in 0..5 { sum += i; } println!("sum is {}", sum); }
This can be puzzling when coming from other languages, where variables can be re-written by default. What makes something a 'variable' is that it gets assigned a computed value at run-time - it is not a constant. It is also how the word is used in mathematics, like when we say 'let n be the largest number in set S'.
There is a reason for declaring variables to be read-only by default. In a larger program, it gets hard to track where writes are taking place. So Rust makes things like mutability ('write-ability') explicit. There's a lot of cleverness in the language, but it tries not to hide anything.
Rust is both statically-typed and strongly-typed - these are often confused, but think of C (statically but weakly typed) and Python (dynamically but strongly typed). In static types the type is known at compile time, and dynamic types are only known at run time.
At the moment, however, it feels like Rust is hiding those types from you. What
exactly is the type of i
? The compiler can work it out, starting with 0,
with type inference, and comes up with i32
(four byte signed integer.)
Let's make exactly one change - turn that 0
into 0.0
. Then we get errors:
error[E0277]: the trait bound `{float}: std::ops::AddAssign<{integer}>` is not satisfied
--> add3.rs:5:9
|
5 | sum += i;
| ^^^^^^^^ the trait `std::ops::AddAssign<{integer}>` is not implemented for `{float}`
|
Ok, so the honeymoon is over: what does this mean? Each operator (like +=
) corresponds
to a trait, which is like an abstract interface that must be implemented for each concrete type.
We'll deal with traits in detail later, but here all you need to know is that
AddAssign
is the name of the trait implementing the +=
operator, and the error is saying
that floating point numbers do not implement this operator for integers. (The full list of
operator traits is here.)
Again, Rust likes to be explicit - it will not silently convert that integer into a float for you.
We have to cast that value to a floating-point value explicitly.
// add3.rs fn main() { let mut sum = 0.0; for i in 0..5 { sum += i as f64; } println!("sum is {}", sum); }
Function Types are Explicit
Functions are one place where the compiler will not work out types for you. And this in fact was a deliberate decision, since languages like Haskell have such powerful type inference that there are hardly any explicit type names. It's actually good Haskell style to put in explicit type signatures for functions. Rust requires this always.
Here is a simple user-defined function:
// fun1.rs fn sqr(x: f64) -> f64 { return x * x; } fn main() { let res = sqr(2.0); println!("square is {}", res); }
Rust goes back to an older style of argument declaration, where the type follows the name. This is how it was done in Algol-derived languages like Pascal.
Again, no integer-to-float conversions - if you replace the 2.0
with 2
then we
get a clear error:
8 | let res = sqr(2);
| ^ expected f64, found integral variable
|
You will actually rarely see functions written using a return
statement. More
often, it will look like this:
# #![allow(unused_variables)] # #fn main() { fn sqr(x: f64) -> f64 { x * x } #}
This is because the body of the function (inside {}
) has the value of its
last expression, just like with if-as-an-expression.
Since semicolons are inserted semi-automatically by human fingers, you might add it here and get the following error:
|
3 | fn sqr(x: f64) -> f64 {
| ^ expected f64, found ()
|
= note: expected type `f64`
= note: found type `()`
help: consider removing this semicolon:
--> fun2.rs:4:8
|
4 | x * x;
| ^
The ()
type is the empty type, nada, void
, zilch, nothing. Everything in Rust
has a value, but sometimes it's just nothing. The compiler knows this is
a common mistake, and actually helps you.
A few more examples of this no-return expression style:
# #![allow(unused_variables)] # #fn main() { // absolute value of a floating-point number fn abs(x: f64) -> f64 { if x > 0.0 { x } else { -x } } // ensure the number always falls in the given range fn clamp(x: f64, x1: f64, x2: f64) -> f64 { if x < x1 { x1 } else if x > x2 { x2 } else { x } } #}
It's not wrong to use return
, but code is cleaner without it. You will still
use return
for returning early from a function.
Some operations can be elegantly expressed recursively:
# #![allow(unused_variables)] # #fn main() { fn factorial(n: u64) -> u64 { if n == 0 { 1 } else { n * factorial(n-1) } } #}
This can be a little strange at first, and the best thing is then to use pencil and paper and work out some examples. It isn't usually the most efficient way to do that operation however.
Values can also be passed by reference. A reference is created by &
and dereferenced
by *
.
fn by_ref(x: &i32) -> i32{ *x + 1 } fn main() { let i = 10; let res1 = by_ref(&i); let res2 = by_ref(&41); println!("{} {}", res1,res2); } // 11 42
What if you want a function to modify one of its arguments? Enter mutable references:
// fun4.rs fn modifies(x: &mut f64) { *x = 1.0; } fn main() { let mut res = 0.0; modifies(&mut res); println!("res is {}", res); }
This is more how C would do it than C++. You have to explicitly pass the
reference (with &
) and explicitly dereference with *
. And then throw in mut
because it's not the default. (I've always felt that C++ references are
too easy to miss compared to C.)
Basically, Rust is introducing some friction here, and not-so-subtly pushing
you towards returning values from functions directly. Fortunately, Rust has
powerful ways to express things like "operation succeeded and here's the result"
so &mut
isn't needed that often. Passing by reference is important when we have a
large object and don't wish to copy it.
The type-after-variable style applies to let
as well, when you really want to nail
down the type of a variable:
# #![allow(unused_variables)] # #fn main() { let bigint: i64 = 0; #}
Learning Where to Find the Ropes
It's time to start using the documentation. This will be installed on your machine,
and you can use rustup doc --std
to open it in a browser.
Note the search field at the top, since this is going to be your friend; it operates completely offline.
Let's say we want to see where the mathematical functions are, so search for 'cos'. The first two hits show it defined for both single and double-precision floating point numbers. It is defined on the value itself as a method, like so:
# #![allow(unused_variables)] # #fn main() { let pi: f64 = 3.1416; let x = pi/2.0; let cosine = x.cos(); #}
And the result will be sort-of zero; we obviously need a more authoritative source of pi-ness!
(Why do we need an explicit f64
type? Because without it, the constant could
be either f32
or f64
, and these are very different.)
Let me quote the example given for cos
, but written as a complete program
( assert!
is a cousin of assert_eq!
; the expression must be true):
fn main() { let x = 2.0 * std::f64::consts::PI; let abs_difference = (x.cos() - 1.0).abs(); assert!(abs_difference < 1e-10); }
std::f64::consts::PI
is a mouthful! ::
means much the same as it does in C++,
(often written using '.' in other languages) - it is a fully qualified name. We get
this full name from the second hit on searching for PI
.
Up to now, our little Rust programs have been free of all that import
and
include
stuff that tends to slow down the discussion of 'Hello World' programs.
Let's make this program more readable with a use
statement:
use std::f64::consts; fn main() { let x = 2.0 * consts::PI; let abs_difference = (x.cos() - 1.0).abs(); assert!(abs_difference < 1e-10); }
Why haven't we needed to do this up to now?
This is because Rust helpfully makes a lot of basic functionality visible without
explicit use
statements through the Rust prelude.
Arrays and Slices
All statically-typed languages have arrays, which are values packed nose to tail in memory. Arrays are indexed from zero:
// array1.rs fn main() { let arr = [10, 20, 30, 40]; let first = arr[0]; println!("first {}", first); for i in 0..4 { println!("[{}] = {}", i,arr[i]); } println!("length {}", arr.len()); }
And the output is:
first 10
[0] = 10
[1] = 20
[2] = 30
[3] = 40
length 4
In this case, Rust knows exactly how big the array is and if you try to
access arr[4]
it will be a compile error.
 We will
come to the Rust equivalent of List
soon, but arrays are not the droids you're looking
for; they are fixed in size. They can be mutable (if we ask nicely) but you
cannot add new elements.
Arrays are not used that often in Rust, because the type of an array includes its
size. The type of the array in the example is
[i32; 4]
; the type of [10, 20]
would be [i32; 2]
and so forth: they
have different types. So they are bastards to pass around as
function arguments.
What are used often are slices. You can think of these as views into an underlying array of values. They otherwise behave very much like an array, and know their size, unlike those dangerous animals C pointers.
Note two important things here - how to write a slice's type, and that
you have to use &
to pass it to the function.
// array2.rs // read as: slice of i32 fn sum(values: &[i32]) -> i32 { let mut res = 0; for i in 0..values.len() { res += values[i] } res } fn main() { let arr = [10,20,30,40]; // look at that & let res = sum(&arr); println!("sum {}", res); }
Ignore the code of sum
for a while, and look at &[i32]
. The relationship between
Rust arrays and slices is similar to that between C arrays and pointers, except for
two important differences - Rust slices keep track of their size (and will
panic if you try to access outside that size) and you have to explicitly say that
you want to pass an array as a slice using the &
operator.
A C programmer pronounces &
as 'address of'; a Rust programmer pronounces it
'borrow'. This is going to be the key word when learning Rust. Borrowing is the name
given to a common pattern in programming; whenever you pass something by reference
(as nearly always happens in dynamic languages) or pass a pointer in C. Anything
borrowed remains owned by the original owner.
Slicing and Dicing
You cannot print out an array in the usual way with {}
but you can do a debug
print with {:?}
.
// array3.rs fn main() { let ints = [1, 2, 3]; let floats = [1.1, 2.1, 3.1]; let strings = ["hello", "world"]; let ints_ints = [[1, 2], [10, 20]]; println!("ints {:?}", ints); println!("floats {:?}", floats); println!("strings {:?}", strings); println!("ints_ints {:?}", ints_ints); }
Which gives:
ints [1, 2, 3]
floats [1.1, 2.1, 3.1]
strings ["hello", "world"]
ints_ints [[1, 2], [10, 20]]
So, arrays of arrays are no problem, but the important thing is that an array contains values of only one type. The values in an array are arranged next to each other in memory so that they are very efficient to access.
If you are curious about the actual types of these variables, here is a useful trick. Just declare a variable with an explicit type which you know will be wrong:
# #![allow(unused_variables)] # #fn main() { let var: () = [1.1, 1.2]; #}
Here is the informative error:
3 | let var: () = [1.1, 1.2];
| ^^^^^^^^^^ expected (), found array of 2 elements
|
= note: expected type `()`
= note: found type `[{float}; 2]`
({float}
means 'some floating-point type which is not fully specified yet')
Slices give you different views of the same array:
// slice1.rs fn main() { let ints = [1, 2, 3, 4, 5]; let slice1 = &ints[0..2]; let slice2 = &ints[1..]; // open range! println!("ints {:?}", ints); println!("slice1 {:?}", slice1); println!("slice2 {:?}", slice2); }
ints [1, 2, 3, 4, 5]
slice1 [1, 2]
slice2 [2, 3, 4, 5]
This is a neat notation which looks similar to Python slices but with a big difference: a copy of the data is never made. These slices all borrow their data from their arrays. They have a very intimate relationship with that array, and Rust spends a lot of effort to make sure that relationship does not break down.
Optional Values
Slices, like arrays, can be indexed. Rust knows the size of an array at
compile-time, but the size of a slice is only known at run-time. So s[i]
can
cause an out-of-bounds error when running and will panic. This is really not
what you want to happen - it can be the difference between a safe launch abort and
scattering pieces of a very expensive satellite all over Florida. And there are
no exceptions.
Let that sink in, because it comes as a shock. You cannot wrap dodgy-may-panic code in some try-block and 'catch the error' - at least not in a way you'd want to use every day. So how can Rust be safe?
There is a slice method get
which does not panic. But what does it return?
// slice2.rs fn main() { let ints = [1, 2, 3, 4, 5]; let slice = &ints; let first = slice.get(0); let last = slice.get(5); println!("first {:?}", first); println!("last {:?}", last); } // first Some(1) // last None
last
failed (we forgot about zero-based indexing), but returned something called None
.
first
is fine, but appears as a value wrapped in Some
. Welcome to the Option
type! It may be either Some
or None
.
 But at least you can call
is_some
first to make sure - for instance, if you had a distinct no-value default:
# #![allow(unused_variables)] # #fn main() { let maybe_last = slice.get(5); let last = if maybe_last.is_some() { *maybe_last.unwrap() } else { -1 }; #}
Note the *
- the precise type inside the Some
is &i32
, which is a reference. We need
to dereference this to get back to a i32
value.
Which is long-winded, so there's a shortcut - unwrap_or
will return the value it
is given if the Option
was None
. The types must match up - get
returns
a reference. so you have to make up a &i32
with &-1
. Finally, again use *
to get the value as i32
.
# #![allow(unused_variables)] # #fn main() { let last = *slice.get(5).unwrap_or(&-1); #}
It's easy to miss the &
, but the compiler has your back here. If it was -1
,
rustc
says 'expected &{integer}, found integral variable' and then
'help: try with &-1
'.
You can think of Option
as a box which may contain a value, or nothing (None
).
(It is called Maybe
in Haskell). It may contain any kind of value, which is
its type parameter. In this case, the full type is Option<&i32>
, using
C++-style notation for generics. Unwrapping this box may cause an explosion,
but unlike Schroedinger's Cat, we can know in advance if it contains a value.
It is very common for Rust functions/methods to return such maybe-boxes, so learn how to use them comfortably.
Vectors
We'll return to slice methods again, but first: vectors. These are re-sizeable
arrays and behave much like Python List
and C++ std::vector
. The Rust type
Vec
(pronounced 'vector') behaves very much like an slice in fact; the
difference is that you can append extra values to a vector - note that it must
be declared as mutable.
// vec1.rs fn main() { let mut v = Vec::new(); v.push(10); v.push(20); v.push(30); let first = v[0]; // will panic if out-of-range let maybe_first = v.get(0); println!("v is {:?}", v); println!("first is {}", first); println!("maybe_first is {:?}", maybe_first); } // v is [10, 20, 30] // first is 10 // maybe_first is Some(10)
A common beginner mistake is to forget the mut
; you will get a helpful error
message:
3 | let v = Vec::new();
| - use `mut v` here to make mutable
4 | v.push(10);
| ^ cannot borrow mutably
There is a very intimate relation between vectors and slices:
// vec2.rs fn dump(arr: &[i32]) { println!("arr is {:?}", arr); } fn main() { let mut v = Vec::new(); v.push(10); v.push(20); v.push(30); dump(&v); let slice = &v[1..]; println!("slice is {:?}", slice); }
That little, so-important borrow operator &
is coercing the vector into a
slice. And it makes complete sense, because the vector is also looking after an array of
values, with the difference that the array is allocated dynamically.
If you come from a dynamic language, now is time for that little talk. In systems languages, program memory comes in two kinds: the stack and the heap. It is very fast to allocate data on the stack, but the stack is limited; typically of the order of megabytes. The heap can be gigabytes, but allocating is relatively expensive, and such memory must be freed later.  Once the system is sure that data is no longer referenced by other data, it goes back into the pool of available memory.
Generally, this is a price worth paying. Playing with the stack is terribly unsafe, because if you make one mistake you can override the return address of the current function, and you die an ignominious death or (worse) got pwned by some guy living in his Mom's basement in Minsk.
The first C program I wrote (on an DOS PC) took out the whole computer. Unix systems always behaved better, and only the process died with a segfault. Why is this worse than a Rust (or Go) program panicking? Because a panic happens when the original problem happens, not when the program has become hopelessly confused and eaten all your homework. Panics are memory safe because they happen before any illegal access to memory. This is a common cause of security problems in C, because all memory accesses are unsafe and a cunning attacker can exploit this weakness.
Panicking sounds desperate and unplanned, but Rust panics are structured - the stack is unwound just as with exceptions. All allocated objects are dropped, and a backtrace is generated.
The downsides of garbage collection? The first is that it is wasteful of memory, which matters in those small embedded microchips which increasingly rule our world. The second is that it will decide, at the worst possible time, that a clean up must happen now. (The Mom analogy is that she wants to clean your room when you are at a delicate stage with a new lover). Those embedded systems need to respond to things when they happen ('real-time') and can't tolerate unscheduled outbreaks of cleaning. Roberto Ierusalimschy, the chief designer of Lua (one of the most elegant dynamic languages ever) said that he would not like to fly on an airplane that relied on garbage-collected software.
Back to vectors: when a vector is modified or created, it allocates from the heap and becomes the owner of that memory. The slice borrows the memory from the vector. When the vector dies or drops, it lets the memory go.
Iterators
We have got so far without mentioning a key part of the Rust puzzle - iterators.
The for-loop over a range was using an iterator (0..n
is actually similar to the
Python 3 range
function).
An iterator is easy to define informally. It is an 'object' with a next
method
which returns an Option
. As long as that value is not None
, we keep calling
next
:
// iter1.rs fn main() { let mut iter = 0..3; assert_eq!(iter.next(), Some(0)); assert_eq!(iter.next(), Some(1)); assert_eq!(iter.next(), Some(2)); assert_eq!(iter.next(), None); }
And that is exactly what for var in iter {}
does.
This may seem an inefficient way to define a for-loop, but rustc
does crazy-ass
optimizations in release mode and it will be just as fast as a while
loop.
Here is the first attempt to iterate over an array:
// iter2.rs fn main() { let arr = [10, 20, 30]; for i in arr { println!("{}", i); } }
which fails, but helpfully:
4 | for i in arr {
| ^ the trait `std::iter::Iterator` is not implemented for `[{integer}; 3]`
|
= note: `[{integer}; 3]` is not an iterator; maybe try calling
`.iter()` or a similar method
= note: required by `std::iter::IntoIterator::into_iter`
Following rustc
's advice, the following program works as expected.
// iter3.rs fn main() { let arr = [10, 20, 30]; for i in arr.iter() { println!("{}", i); } // slices will be converted implicitly to iterators... let slice = &arr; for i in slice { println!("{}", i); } }
In fact, it is more efficient to iterate over an array or slice this way
than to use for i in 0..slice.len() {}
because Rust does not have to obsessively
check every index operation.
We had an example of summing up a range of integers earlier. It involved a mut
variable and a loop. Here's the idiomatic, pro-level way of doing the sum:
// sum1.rs fn main() { let sum: i32 = (0..5).sum(); println!("sum was {}", sum); let sum: i64 = [10, 20, 30].iter().sum(); println!("sum was {}", sum); }
Note that this is one of those cases where you need to be explicit about the type of the variable, since otherwise Rust doesn't have enough information. Here we do sums with two different integer sizes, no problem. (It is also no problem to create a new variable of the same name if you run out of names to give things.)
With this background, some more of the slice methods will make more sense. (Another documentation tip; on the right-hand side of every doc page there's a '[-]' which you can click to collapse the method list. You can then expand the details of anything that looks interesting. Anything that looks too weird, just ignore for now.)
The windows
method gives you an iterator of slices - overlapping windows of
values!
// slice4.rs fn main() { let ints = [1, 2, 3, 4, 5]; let slice = &ints; for s in slice.windows(2) { println!("window {:?}", s); } } // window [1, 2] // window [2, 3] // window [3, 4] // window [4, 5]
Or chunks
:
# #![allow(unused_variables)] # #fn main() { for s in slice.chunks(2) { println!("chunks {:?}", s); } // chunks [1, 2] // chunks [3, 4] // chunks [5] #}
More about vectors...
There is a useful little macro vec!
for initializing a vector. Note that you
can remove values from the end of a vector using pop
, and extend a vector
using any compatible iterator.
// vec3.rs fn main() { let mut v1 = vec![10, 20, 30, 40]; v1.pop(); let mut v2 = Vec::new(); v2.push(10); v2.push(20); v2.push(30); assert_eq!(v1, v2); v2.extend(0..2); assert_eq!(v2, &[10, 20, 30, 0, 1]); }
Vectors compare with each other and with slices by value.
You can insert values into a vector at arbitrary positions with insert
,
and remove with remove
. This is not as efficient as pushing and popping since
the values will have to be moved to make room, so watch out for these operations on big
vectors.
Vectors have a size and a capacity. If you clear
a vector, its size becomes zero,
but it still retains its old capacity. So refilling it with push
, etc only requires
reallocation when the size gets larger than that capacity.
Vectors can be sorted, and then duplicates can be removed - these operate in-place
on the vector. (If you want to make a copy first, use clone
.)
// vec4.rs fn main() { let mut v1 = vec![1, 10, 5, 1, 2, 11, 2, 40]; v1.sort(); v1.dedup(); assert_eq!(v1, &[1, 2, 5, 10, 11, 40]); }
Strings
Strings in Rust are a little more involved than in other languages; the String
type,
like Vec
, allocates dynamically and is resizeable. (So it's like C++'s std::string
but not like the immutable strings of Java and Python.) But a program may contain a lot
of string literals (like "hello") and a system language should be able to store
these statically in the executable itself. In embedded micros, that could mean putting
them in cheap ROM rather than expensive RAM (for low-power devices, RAM is
also expensive in terms of power consumption.) A system language has to have
two kinds of string, allocated or static.
So "hello" is not of type String
. It is of type &str
(pronounced 'string slice').
It's like the distinction between const char*
and std::string
in C++, except
&str
is much more intelligent. In fact, &str
and String
have a very
similar relationship to each other as do &[T]
to Vec<T>
.
// string1.rs fn dump(s: &str) { println!("str '{}'", s); } fn main() { let text = "hello dolly"; // the string slice let s = text.to_string(); // it's now an allocated string dump(text); dump(&s); }
Again, the borrow operator can coerce String
into &str
, just as Vec<T>
could
be coerced into &[T]
.
Under the hood, String
is basically a Vec<u8>
and &str
is &[u8]
, but
those bytes must represent valid UTF-8 text.
Like a vector, you can push
a character and pop
one off the end of String
:
// string5.rs fn main() { let mut s = String::new(); // initially empty! s.push('H'); s.push_str("ello"); s.push(' '); s += "World!"; // short for `push_str` // remove the last char s.pop(); assert_eq!(s, "Hello World"); }
You can convert many types to strings using to_string
(if you can display them with '{}' then they can be converted).
The format!
macro is a very useful way to build
up more complicated strings using the same format strings as println!
.
// string6.rs fn array_to_str(arr: &[i32]) -> String { let mut res = '['.to_string(); for v in arr { res += &v.to_string(); res.push(','); } res.pop(); res.push(']'); res } fn main() { let arr = array_to_str(&[10, 20, 30]); let res = format!("hello {}", arr); assert_eq!(res, "hello [10,20,30]"); }
Note the &
in front of v.to_string()
- the operator is defined on a string
slice, not a String
itself, so it needs a little persuasion to match.
The notation used for slices works with strings as well:
// string2.rs fn main() { let text = "static"; let string = "dynamic".to_string(); let text_s = &text[1..]; let string_s = &string[2..4]; println!("slices {:?} {:?}", text_s, string_s); } // slices "tatic" "na"
But, you cannot index strings! This is because they use the One True Encoding, UTF-8, where a 'character' may be a number of bytes.
// string3.rs fn main() { let multilingual = "Hi! ¡Hola! привет!"; for ch in multilingual.chars() { print!("'{}' ", ch); } println!(""); println!("len {}", multilingual.len()); println!("count {}", multilingual.chars().count()); let maybe = multilingual.find('п'); if maybe.is_some() { let hi = &multilingual[maybe.unwrap()..]; println!("Russian hi {}", hi); } } // 'H' 'i' '!' ' ' '¡' 'H' 'o' 'l' 'a' '!' ' ' 'п' 'р' 'и' 'в' 'е' 'т' '!' // len 25 // count 18 // Russian hi привет!
Now, let that sink in - there are 25 bytes, but only 18 characters! However, if
you use a method like find
, you will get a valid index (if found) and then
any slice will be fine.
(The Rust char
type is a 4-byte Unicode code point. Strings are not arrays
of chars!)
String slicing may explode like vector indexing, because it uses byte offsets. In this case, the string consists of two bytes, so trying to pull out the first byte is a Unicode error. So be careful to only slice strings using valid offsets that come from string methods.
# #![allow(unused_variables)] # #fn main() { let s = "¡"; println!("{}", &s[0..1]); <-- bad, first byte of a multibyte character #}
Breaking up strings is a popular and useful pastime. The string split_whitespace
method returns an iterator, and we then choose what to do with it. A common need
is to create a vector of the split substrings.
collect
is very general and so needs some clues about what it is collecting - hence
the explicit type.
# #![allow(unused_variables)] # #fn main() { let text = "the red fox and the lazy dog"; let words: Vec<&str> = text.split_whitespace().collect(); // ["the", "red", "fox", "and", "the", "lazy", "dog"] #}
You could also say it like this, passing the iterator into the extend
method:
# #![allow(unused_variables)] # #fn main() { let mut words = Vec::new(); words.extend(text.split_whitespace()); #}
In most languages, we would have to make these separately allocated strings, whereas here each slice in the vector is borrowing from the original string. All we allocate is the space to keep the slices.
Have a look at this cute two-liner; we get an iterator over the chars,
and only take those characters which are not space. Again, collect
needs
a clue (we may have wanted a vector of chars, say):
# #![allow(unused_variables)] # #fn main() { let stripped: String = text.chars() .filter(|ch| ! ch.is_whitespace()).collect(); // theredfoxandthelazydog #}
The filter
method takes a closure, which is Rust-speak for
lambdas or anonymous functions. Here the argument type is clear from the
context, so the explicit rule is relaxed.
Yes, you can do this as an explicit loop over chars, pushing the returned slices into a mutable vector, but this is shorter, reads well (when you are used to it, of course) and just as fast. It is not a sin to use a loop, however, and I encourage you to write that version as well.
Interlude: Getting Command Line Arguments
Up to now our programs have lived in blissful ignorance of the outside world; now it's time to feed them data.
std::env::args
is how you access command-line arguments; it returns an iterator
over the arguments as strings, including the program name.
// args0.rs fn main() { for arg in std::env::args() { println!("'{}'", arg); } }
src$ rustc args0.rs
src$ ./args0 42 'hello dolly' frodo
'./args0'
'42'
'hello dolly'
'frodo'
Would it have been better to return a Vec
? It's easy enough to use collect
to
make that vector, using the iterator skip
method to move past the program
name.
# #![allow(unused_variables)] # #fn main() { let args: Vec<String> = std::env::args().skip(1).collect(); if args.len() > 0 { // we have args! ... } #}
Which is fine; it's pretty much how you would do it in most languages.
A more Rust-y approach to reading a single argument (together with parsing an integer value):
// args1.rs use std::env; fn main() { let first = env::args().nth(1).expect("please supply an argument"); let n: i32 = first.parse().expect("not an integer!"); // do your magic }
nth(1)
gives you the second value of the iterator, and expect
is like an unwrap
with a readable message.
Converting a string into a number is straightforward, but you do need to specify
the type of the value - how else could parse
know?
This program can panic, which is fine for dinky test programs. But don't get too comfortable with this convenient habit.
Matching
The code in string3.rs
where we extract the Russian greeting is not how it would
be usually written. Enter match:
# #![allow(unused_variables)] # #fn main() { match multilingual.find('п') { Some(idx) => { let hi = &multilingual[idx..]; println!("Russian hi {}", hi); }, None => println!("couldn't find the greeting, Товарищ") }; #}
match
consists of several patterns with a matching value following the fat arrow,
separated by commas. It has conveniently unwrapped the value from the Option
and
bound it to idx
. You must specify all the possibilities, so we have to handle
None
.
Once you are used to it (and by that I mean, typed it out in full a few times) it
feels more natural than the explicit is_some
check which needed an extra
variable to store the Option
.
But if you're not interested in failure here, then if let
is your friend:
# #![allow(unused_variables)] # #fn main() { if let Some(idx) = multilingual.find('п') { println!("Russian hi {}", &multilingual[idx..]); } #}
This is convenient if you want to do a match and are only interested in one possible result.
match
can also operate like a C switch
statement, and like other Rust constructs
can return a value:
# #![allow(unused_variables)] # #fn main() { let text = match n { 0 => "zero", 1 => "one", 2 => "two", _ => "many", }; #}
The _
is like C default
- it's a fall-back case. If you don't provide one then
rustc
will consider it an error. (In C++ the best you can expect is a warning, which
says a lot about the respective languages).
Rust match
statements can also match on ranges. Note that these ranges have
three dots and are inclusive ranges, so that the first condition would match 3.
# #![allow(unused_variables)] # #fn main() { let text = match n { 0...3 => "small", 4...6 => "medium", _ => "large", }; #}
Reading from Files
The next step to exposing our programs to the world is to reading files.
Recall that expect
is like unwrap
but gives a custom error message. We are
going to throw away a few errors here:
// file1.rs use std::env; use std::fs::File; use std::io::Read; fn main() { let first = env::args().nth(1).expect("please supply a filename"); let mut file = File::open(&first).expect("can't open the file"); let mut text = String::new(); file.read_to_string(&mut text).expect("can't read the file"); println!("file had {} bytes", text.len()); }
src$ file1 file1.rs
file had 366 bytes
src$ ./file1 frodo.txt
thread 'main' panicked at 'can't open the file: Error { repr: Os { code: 2, message: "No such file or directory" } }', ../src/libcore/result.rs:837
note: Run with `RUST_BACKTRACE=1` for a backtrace.
src$ file1 file1
thread 'main' panicked at 'can't read the file: Error { repr: Custom(Custom { kind: InvalidData, error: StringError("stream did not contain valid UTF-8") }) }', ../src/libcore/result.rs:837
note: Run with `RUST_BACKTRACE=1` for a backtrace.
So open
can fail because the file doesn't exist or we aren't allowed to read it,
and read_to_string
can fail because the file doesn't contain valid UTF-8. (Which is
fair enough, you can use read_to_end
and put the contents into a vector of bytes
instead.) For files that aren't too big, reading them in one gulp is useful and
straightforward.
If you know anything about file handling in other languages, you may wonder when
the file is closed. If we were writing to this file, then not closing it could
result in loss of data.
But the file here is closed when the function ends and the file
variable is dropped.
This 'throwing away errors' thing is getting too much of a habit. You do not
want to put this code into a function, knowing that it could so easily crash
the whole program. So now we have to talk about exactly what File::open
returns.
If Option
is a value that may contain something or nothing, then Result
is a value
that may contain something or an error. They both understand unwrap
(and its cousin
expect
) but they are quite different. Result
is defined by two type parameters,
for the Ok
value and the Err
value.
The Result
'box' has two compartments, one labelled Ok
and the other Err
.
fn good_or_bad(good: bool) -> Result<i32,String> { if good { Ok(42) } else { Err("bad".to_string()) } } fn main() { println!("{:?}",good_or_bad(true)); //Ok(42) println!("{:?}",good_or_bad(false)); //Err("bad") match good_or_bad(true) { Ok(n) => println!("Cool, I got {}",n), Err(e) => println!("Huh, I just got {}",e) } // Cool, I got 42 }
(The actual 'error' type is arbitrary - a lot of people use strings until they are comfortable with Rust error types.) It's a convenient way to either return one value or another.
This version of the file reading function does not crash. It returns a Result
and
it is the caller who must decide how to handle the error.
// file2.rs use std::env; use std::fs::File; use std::io::Read; use std::io; fn read_to_string(filename: &str) -> Result<String,io::Error> { let mut file = match File::open(&filename) { Ok(f) => f, Err(e) => return Err(e), }; let mut text = String::new(); match file.read_to_string(&mut text) { Ok(_) => Ok(text), Err(e) => Err(e), } } fn main() { let file = env::args().nth(1).expect("please supply a filename"); let text = read_to_string(&file).expect("bad file man!"); println!("file had {} bytes", text.len()); }
The first match safely extracts the value from Ok
, which
becomes the value of the match. If it's Err
it returns the error,
rewrapped as an Err
.
The second match returns the string, wrapped up as an Ok
, otherwise
(again) the error. The actual value in the Ok
is unimportant, so we ignore
it with _
.
This is not so pretty; when most of a function is error handling, then the 'happy path' gets lost. Go tends to have this problem, with lots of explicit early returns, or just ignoring errors. (That is, by the way, the closest thing to evil in the Rust universe.)
Fortunately, there is a shortcut.
The std::io
module defines a type alias io::Result<T>
which is exactly
the same as Result<T,io::Error>
and easier to type.
# #![allow(unused_variables)] # #fn main() { fn read_to_string(filename: &str) -> io::Result<String> { let mut file = File::open(&filename)?; let mut text = String::new(); file.read_to_string(&mut text)?; Ok(text) } #}
That ?
operator does almost exactly what the match on File::open
does;
if the result was an error, then it will immediately return that error.
Otherwise, it returns the Ok
result.
At the end, we still need to wrap up the string as a result.
2017 was a good year for Rust, and ?
was one of the cool things that
became stable. You will still see the macro try!
used in older code:
# #![allow(unused_variables)] # #fn main() { fn read_to_string(filename: &str) -> io::Result<String> { let mut file = try!(File::open(&filename)); let mut text = String::new(); try!(file.read_to_string(&mut text)); Ok(text) } #}
In summary, it's possible to write perfectly safe Rust that isn't ugly, without needing exceptions.


SPDY/HTTP2.0
Speech API
Promises
CSP
Translators to Javascript
ES2015
JavaScript - past, present and future
AMP
Security
Future
Web components
Rust language
Web assembly
TLS and HTTPS
Testing
SSL/TLS
Algorithms and Data Structures


{% extends "_page.html" %}
{% block intro %}
Generics (or templates) allow methods and classes to manipulate generic data types.
{% endblock %}
{% block description %}
Rust's type system allows it to determine the types used in GenericStruct
and do_nothing without needing to specify the exact type. Whereas in both C++ and Java
types must be specified for the classes.
{% endblock %}


title=Chinese Weather date=2012-12-26 type=post tags=blog status=published ~~~~~~
In related news, I woke up to rain today. it's freaking cold in China. Northern parts of China - like Harbin - already cold enough that it's famous for its ice festivals in which amazing and beautiful ice structures are constructed in a true winter-wonderland fashion - have seen daytime HIGHS of -22C. Nanjing, which is an hour's train ride from Shanghai, where I am, hit -6 C for daytime lows. And, when the SpringSource team and I were in Beijing for SpringOne Beijing 2012 we routinely hit temperatures of -8 or -9C. Brrr! I hope you're warmer, wherever you are.
I'm originally from Los Angeles, and sometimes gets, and while I'm now in rainy San Francisco, I'm not used to this kind of cold. I much prefer the cold to the hot mugginess of a humid summer, however, so I suppose this will just have to do.
As you can imagine, slingshotting from Beijing, China (at -8C) to Hyderabad and Bangalore in India, where it's a warm 30 C or so, has not been easy on the immune system. I've got a cold. Oh well..


Home
About Us
Introduction
Company Structure
Our Culture
Our Business
Completed Projects
Current Projects
Awards
Contact Us
CONTACT US
Welltech Construction Pte Ltd 61 Ubi Avenue 1, UB Point, #05-16, Singapore 408941
T: 6299 2858 F: 6299 2821
E<EMAIL_ADDRESS>Your Name
Your Email
Subject
Message
Send


This demonstrates how to synchronize or "bridge" methods between tabs. A shared dependency is required, who's method's can be bridged, which is achieved via using localStorage. Bridged methods, when fired, will trigger in all tabs with the same arguments used for each.
Open several tabs using the "open new tab" link below, and open dev tools so you can see the console output. Then click the "invoke shared event" link here; each tab's console will show the same function has been invoked in each tab, with the same args.
open new tab |
invoke shared event


Ex Machina, the greatest motion picture ever produced revolving around the themes of artificial intelligence and human psychology, and one of the very few movies that I actually enjoyed, was just a few buttons away, in the Plex collection of a friend whom I currently stay with.
This afternoon while I was eating my cereal I turned on the LCD and let the movie played in the background as I sat lazily on the canapé, enjoying my breakfast in the most leisurely manner possible. It then suddenly hit me that the plot certainly felt as if it was progressing faster than it felt the first time I watched the movie.
In the blink of an eye the story was already in stage X, that was how it felt like.
Further introspection suggested that this phenomenon is not limited to just movies, but that there is clearly a discrepancy between our awareness about the flow of time when we re-watched a video for the second time, and that of when we watched it for the first time.
Is it a consequence of how consistent the neural networks are responding to the ever-changing visual stimuli in according to our intuitive expectation of how they would respond since we have already experienced beforehand what we are experiencing?
Or perhaps is it because we are prompted to compute what visual stimuli we should expect to receive next, as a response to the ever-changing visual stimuli, and the efficiency of the computation, together with the accuracy of the result, give us a feeling, which, compared to what we previously felt the first time when we watched the video, made us feel like things are going so much smoother and quicker this time?
It is undeniable that memories affect the way one experiences time. But in the 21st century it remains an open question at to how the brain perceives time.
Related: chronostasis


|
||||||||||
| PREV NEXT | FRAMES NO FRAMES |
| Deprecated Classes | |
|---|---|
| matlabcontrol.extensions.CallbackMatlabProxy
This class was provided as a workaround when MatlabProxy could not operate on the Event Dispatch
Thread (EDT) used by AWT and Swing; MatlabProxy no longer has this limitation.
Wraps around a MatlabProxy making the method calls which interact with MATLAB operate with callbacks instead
of return values. For each method in MatlabProxy that interacts with MATLAB, the same method exists but has
one additional parameter that is either CallbackMatlabProxy.MatlabCallback or CallbackMatlabProxy.MatlabDataCallback . Method invocations do
not throw MatlabInvocationException s, but if the proxy throws a MatlabInvocationException it will be
provided to the callback.
All interactions with the proxy will be done in a single threaded manner. The underlying proxy methods will be completed in the order their corresponding methods in this class were called. Because method invocations on the proxy occur on a separate thread from the one calling the methods in this class, it can be used from within MATLAB on the Event Dispatch Thread (EDT). This class is unconditionally thread-safe. There are no guarantees about the relative ordering of method completion when methods are invoked both on an instance of this class and on the proxy provided to it. |
|
| matlabcontrol.extensions.MatlabProxyLogger
Replaced by LoggingMatlabProxy .
Wraps around a MatlabProxy to provide a log of interactions. The data is not altered. This logger is useful
for determining the Java types and structure of data returned from MATLAB.
Entering a method, exiting a method, and throwing an exception are logged. Method parameters and return values are logged. The contents of a returned array will be recursively explored and its contents logged. As is convention, all of these interactions are logged at Level.FINER . If the logging system has not been otherwise configured,
then the ConsoleHandler which prints log messages to the console will not show these log messages as their
level is too low. To configure the ConsoleHandler to show these log messages, call
MatlabProxyLogger.showInConsoleHandler() .
This class is unconditionally thread-safe. |
|
||||||||||
| PREV NEXT | FRAMES NO FRAMES |


|
Apache Mesos
|
The MetadataManager tracks the Docker images cached by the provisioner that are stored on disk. More...
#include <metadata_manager.hpp>
Public Member Functions | |
| ~MetadataManager () | |
| process::Future< Nothing > | recover () |
| Recover all stored Image and its layer references. More... | |
| process::Future< Image > | put (const ::docker::spec::ImageReference &reference, const std::vector< std::string > &layerIds) |
| Create an Image, put it in metadata manager and persist the reference store state to disk. More... | |
| process::Future< Option< Image > > | get (const ::docker::spec::ImageReference &reference, bool cached) |
| Retrieve Image based on image reference if it is among the Images stored in memory. More... | |
Static Public Member Functions | |
| static Try< process::Owned < MetadataManager > > | create (const Flags &flags) |
The MetadataManager tracks the Docker images cached by the provisioner that are stored on disk.
It keeps track of the layers that Docker images are composed of and recovers Image objects upon initialization by checking for dependent layers stored on disk. Currently, image layers are stored indefinitely, with no garbage collection of unreferenced image layers.
| mesos::internal::slave::docker::MetadataManager::~MetadataManager | ( | ) |
|
static |
| process::Future<Option<Image> > mesos::internal::slave::docker::MetadataManager::get | ( | const ::docker::spec::ImageReference & | reference, |
| bool | cached | ||
| ) |
| process::Future<Image> mesos::internal::slave::docker::MetadataManager::put | ( | const ::docker::spec::ImageReference & | reference, |
| const std::vector< std::string > & | layerIds | ||
| ) |
Create an Image, put it in metadata manager and persist the reference store state to disk.
| process::Future<Nothing> mesos::internal::slave::docker::MetadataManager::recover | ( | ) |
Recover all stored Image and its layer references.


package test
Ordering
- Alphabetic
Visibility
- Public
- All
Type Members
-
class
test_AkkaBuilder extends TestKit with ImplicitSender with WordSpecLike with Matchers with BeforeAndAfterAll
Copyright Canusi
-
class
test_AkkaBuilderNegativeSpec extends TestKit with ImplicitSender with WordSpecLike with Matchers with BeforeAndAfterAll
Copyright Canusi
- class test_Schedulerextends extends TestKit with ImplicitSender with WordSpecLike with Matchers with BeforeAndAfterAll
Value Members
-
object
TestActorSystem extends AkkaSystem
Copyright Canusi
Copyright Canusi
- Since
2020-05-19 15:08 This class is necessary because: This class supports the business purpose:
-
object
TestGraphArtifacts
Copyright Canusi
- object TestJobs
- object TestSourceDelayed extends GraphSource[Int]


Package com.jme.terrain
Interface ProgressMonitor
-
public interface ProgressMonitor
Monitor the progress of an expensive terrain operation. Monitors are passed into the expensive operations, and those operations call the incrementProgress method whenever they determine that progress has changed. It is up to the monitor to determine if the increment is percentage or a unit of another measure, but anything calling it should use the setMonitorMax() method and make sure incrementProgress() match up in terms of units.- Author:
- Brent Owens
-
-
Method Summary
All Methods Instance Methods Abstract Methods Modifier and Type Method Description float
getMonitorMax()
The max value of the progress.void
incrementProgress(float increment)
Increment the progress by a unit.void
progressComplete()
The progress has completedvoid
setMonitorMax(float max)
The max value that when reached, the progress is at 100%.
-
-
-
Method Detail
-
incrementProgress
void incrementProgress(float increment)
Increment the progress by a unit.
-
setMonitorMax
void setMonitorMax(float max)
The max value that when reached, the progress is at 100%.
-
getMonitorMax
float getMonitorMax()
The max value of the progress. When incrementProgress() reaches this value, progress is complete
-
progressComplete
void progressComplete()
The progress has completed
-
-


View the new face of EarthWeb.com
|
|
|
1000
Welcome to the ITKnowledge Desktop Library. Search, browse and read trusted books and guides to learn more about the applications you use every day. Our Editors have carefully chosen a selection of books from our full ITKnowledge Enterprise library that places needed information at your fingertips.
Get quick answers! Study a new feature! Learn a new application!
|
|
Browse by Topic: Drill down through the topics to find answers fast.
|
|
Email / Groupware
MS Outlook, MS Exchange, ... |
Operating Systems
Mac OS, Palm OS, Windows 2000, Windows 98, Windows 95, Windows NT |
Internet
How to use the internet, ... |
Web Page Design
MS FrontPage, HTML, ... |
|
Click here to view all books! |
|
We have more great content arriving all the time.
Click here to see what's coming soon!
|
|
|
|
|


Yes, I have made softwares! :) The most interesting part is:- it is not by any drag and drop application. I made it using python. Python is a very powerful programing language. It is used in almost all areas of programing. So, I made several softwares using it. I have also gave a name to my software making company "Zcorp". I had sooo much fun making. Some of them are listed below:
- Zweather
It is a weather forecasting software. Using it you can get weather information about all cities in the world! I have used openweathermap api for getting the info. You will have to just give the name of your city and it'll get info about it. I've tried to give it a stylish look as much as I can. You can, of course suggest me for any modification you want. You can find me in Github. You are also welcome to contrubute in this project if you find any bug.
I have made two versions of it. A portable version and an installer. You can download from bellow as you wish. Oh! I forgot, the password is Zcorp.
- Portable version: Zweather 1.5 Size: 10.3MB
- Installer version: Zweather 1.5 Size: 9.1MB
Screenshot of Zweather
- Zcurrency
This is one of my favorate softwares. Using it you can get updated exhange rate of any currency you want. I have also provided the full meaning of any curreny code i.e BDT stands BanglaDeshi Taka. I think it'll be helpful for commercial use. I have tried to make it as simple as I can. I have given a simple look to it. If you have any suggestion to improve it or have found any bug, please contact me. You can find me on Github. Installation password is Zcorp.
- Installer version: Zcurrency 1.0 Size: 9.1MB
Screenshot of Zcurrency
- Ztube
This is a youtube video downloading software. Using it, you can download almost every youtube video.  But it is a console applocation. It's not GUI(Graphical User Interface) program like the two others. You will have to give command to download videos.It's password is Zcorp.
- Installer version: Ztube 1.0 Size: 9.1MB


Cactus are great for decorations.  To plant a cactus, grab a pot, some soil, and a cactus seed. Water bi-weekly. Cactus seeds can be purchased online or in garden centers.
20-25mins


Image segmentation is the process of identifying areas in an image according to some criteria. Tree segmentation, which refers to the identification of trees in images, is required to identify trees in DEMs as these are the areas where ground height must be estimated, using image segmentation techniques.
The aim of this project was to identify trees
in orchard DEMs. As no other data was used (such as visible spectrum aerial
photographs) and as the DEMs were of low-fidelity, accurate segmentation was more
difficult to achieve.
We aimed to investigate the usage of different segmentation techniques on DEMs. There are many characteristics of DEMs that affect segmentation accuracy, such as noise, tree spacing and land gradient, and these were looked at.  Simple Linear Iterative Clustering (SLIC) is a way of grouping pixels into superpixels. SLIC works by electing k centroids in the image, evenly spaced apart. The Euclidean distance between each pixel and each centroid is calculated - some optimisation is used to limit the number of calculations done. Pixels are assigned to their closet centroid, forming a cluster, seen in Fig. 1. The centre of each centroid is calculated and this becomes the new centroid. Pixels are assigned to centroids again and this process repeats until centroid positions no longer change or a certain iteration count has been reached.
Figure 1: An image showing SLIC cluster boundaries in cyan.
Watershed segmentation is an image processing technique that segments an image based on the concept of watersheds and catchment basins. Markers are placed in low-lying regions (it is up the user to decide what constitues as a low or high region) and a "flood" is performed where neighbouring pixels are assigned to the basin formed by the marker. When clusters meet (in high-lying regions), they form a watershed along their border. These watersheds segment the image.
Two datasets were used. The first of which, provided by Aerobotics, consisted of greyscale, 32-bit float TIFF images (seen in Fig. 2). These DEMs presented a challenge to the segmentation algorithm due to their low fidelity (the height profile of a sample of the DEM can be seen in Fig. 3). The second set of DEMs were produced by the DEM Generation subproject (seen in Fig. 4). The aim of this was to create a variety of DEMs to test the segmentation algortihm on different types of terrain.
Figure 4: A synthetic DEM from the DEM Generation subproject,
A series of steps was required to perform the tree segmentation operation. DEMs underwent preprocessing to increase to increase the accuracy of segmentation. A system diagram can be in Fig. 5.
Figure 5: System diagram showing the preprocessing, segmentation and evaluation frameworks.
To evaluate segmentation, the results produced from this system must be compared with a ground truth, which is an image that has already been segmented with a higher accuracy than what can be produced by the system. There were 4 tests performed:
Figure 6: The IOU equation.
Marker detection was better in disperse orchards. The window size of the local maxima dectection operation, compared to the spacing of the trees, would have affected this.
| Terrain | Total Trees | % of Trees Identified | Mean Distance from Centre (in Pixels) | Standard Deviation |
|---|---|---|---|---|
| Flat | 711 | 98.312 | 0.308 | 0.325 |
| Gentle | 530 | 95.849 | 0.350 | 0.440 |
| Steep | 540 | 95.926 | 0.376 | 0.430 |
| Large-hilled | 466 | 82.403 | 1.257 | 2.366 |
| Small-hilled | 568 | 94.014 | 0.403 | 0.479 |
Table 1: Table showing the results from the tree centre detection.
The algorthm performed better in smooth trees (seen in Fig. 7) as watershed is sensitive noise. The gradient of terrain was also shown to have an impact on segmentation accuracy, as the algortihm produced more accurate segments in the flat terrain, where 73% of trees have an IOU of 70% or more.
Figure 7: A series of graphs showing the percentages of trees that obtained a certain IOU percentage (shown in the legend), when using different subcategories of terrains in the flat terrain (a), gentle terrain (b), steep terrain (c), large-hilled terrain (d) and small-hilled terrain (e).
From Fig. 8 it can be seen that the algotihm produces many false positive segments in small-hilled terrain, that is not shown in Fig. 7, that results in its overall IOU (24.3%) being much lower than its mean IOU per tree (80.2%), in one case.
Figure 8: A series of images showing the tree masks produced, and their IOU percentage (as shown in the legend above), for the flat terrain (a), steep terrain (b), large-hilled terrain (c) and small-hilled terrain (d).
From Fig. 9, it can be seen that segmentation accuracy is best when using both SLIC and watershed. SLIC alone performs better than watershed alone, as watershed is more sensitive to noise. As SLIC has a much larger execution time than watershed, watershed alone can used in time sensitive circumstances.
Figure 9: A series of graphs showing the percentages of trees that obtained a certain IOU percentage (shown in the legend), when using a certain segmentation technique, for the flat terrain (a), gentle terrain (b) and small-hilled terrain (c).
The results of the segmentation varied depending on the DEMs used. In a best case scenario, where trees are smooth topped, a mean IOU per tree of 88.16% can be achieved while in the worst case scenario, in a DEM with noisy, compacted trees on a large hill, a mean IOU per tree of 54.3% can be achieved. As a result, this system may be usable on orchards with spaced-out identical trees. However, more work is required to make it robust enough to operate with uneven terrain. Using a combination of SLIC and watershed has been shown to be more effective than using only one of them.
created with
Website Builder Software .


Directions: You will be given a random number at the start of the game.
There are four crystals below. By clicking on a crystal you will add a specific amount of points to you total score.
You win the game by matching your total score to the random number. You lose if your total score goes above the random number.
The value of each crystal is hidden from you until you click on it.
Each time when the game starts, the game will change the values of each crystal.


Test purpose
Drag and drop the element to test its sensors correctly collide with underlying canvas entitys
- Create a set of blocks to act as the grid over which the test element will be dragged
- Perform artefact collision checks between the element and the grid group, updating colliding grid entitys to show that they are in collision
- Drag and drop the element across the stack canvas, to check that element's sensors are correctly positioned and the artefact collision detection works as expected
- Vary the element's attributes (handle, offset, 3d-rotation, scale) to make sure its sensors correctly account for these changes
Touch test: should work as expected
Annotated code


{% load staticfiles %}
Cycle X-Pro
Toggle Navigation
X Dash
Download
Menu 1
Sub 1
Sub 2
Past Sessions
{% for file in filelist %}
{{file}}
{% endfor %}
No Plot Selected
Delete
Speed
Distance
Calories


This is the landing page of the (to be built) Spotify App. Somehow, It will use the Spotify API to give you all your playlists & relted information as a CSV.
A good use case would be to uncouple your Spotify and Facebook accounts. Currently, you're forced to create a new account if you want to uncouple Spotify and Facebook, if you've created your Spotify Account using Facebook, which is the same mistake I made.
The downside is, you'll lose all your playlists and saved music. So, besides giving you a .csv file of your playlists for your pleasure and convenience, this ncie little website / webapp will allow you to download all your playlists and upload them to your newly created user account.
{Something with authorizing this web app / page to use your Spotify account.}
{Something with getting all songs for all playlists}
{Something with storing those songs}
{Something with sending them to a new Spotify Account}


title: Page Not Found {% extends "base.html" %} {% block body %}
Nothing to worry about. You can either search our site for what you are looking for or go back to our homepage.
... or look at this random animated kitten gif for a while ...
Powered by The Cat API.


{% load static %}
I love coding, doing research and collaborating
3 months after writing my first Hello World program on September 8th 2012 (While Studying in Centre Point School ,Nagpur) Thats when I realized that computers are the coolest things in the world . There are some little people who are really able to work for there passion, and I sure do appreciate the opportunity that has been given to me.
I find web development to be a sector where a person can use both creativity and logic . I started by making a static website for a startup, now responsible for making my official institute alumni portal.
From this you’ll see that I’m someone that jumps before I can talk myself out of doing something scary.
Designed, built, and managed a Static website as a sole developer. One of my first formal web development projects. Helped a non-tech-company to bring their online presence.
Made a prototype of the Learning Management system. Also worked on other microservices of their projects. Awarded the best intern award.
Got a perception of a smart cooperate culture. Worked on technical as well as non-technical projects. Worked in python and Django in JP Morgan & learned about work ethics in Microsoft.
PS: Working on Django, MySql and Java(DS & Algo).
Reverse Engineer & Build Ugly Prototypes First.
I can learn just about anything by having a final product to tear apart piece by piece. I break the code where I need to figure out why things work the way they do. Documentation is just a reference.
After almost three years of working in the Thakur College Technical team, the goal is to surround me with creative people, who love what they do and work on something which actually has an impact on the lives of people.
Aside from building small projects I would love to enter a position where I can be part of a bigger team & learn from others with more experience than myself.