CARA AJAR KUCING BUANG AIR A.K.A BERAK DI TANDAS..

Apa yang perlu anda tahu ialah kucing memiliki sifat 'this is my territory' means dimana kawasan yang dia sudah mark, disitulah kawasan yang akan dia lalui setiap hari. Kawasan yang ditanda samada tempat untuk dia makan, tempat tidur, tempat bersantai, tempat bermain dan tempat membuang najis.

Perlu juga anda, penggemar tahap dewa makhluk berbulu ini adalah, kucing akan membuang najisnya di tempat yang sunyi..macam kita juga la kaann..kalau berak tu tamo ada yang nampak even lipas sekalipun, kita akan malu, begitu juga dengan kucing.

Ia akan berak di kawasan sunyi seperti sebelah/belakang peti ais, sebelah meja/sofa, sudut-sudut yang manusia tidak lalui dan tempat2 gelap. Kadang-kadang kucing juga berak atas pakaian dan carpet.

Sekiranya kucing anda berak di tempat yang tidak sepatutnya, jangan marah.,ada juga yang memukul kucing tanda tidak setuju dengan kelakuannya, No! Dont! itu hanya akan membuatkan kucing anda mengulangi perbuatannya dan mengalami stress! Apa yang perlu dilakukan adalah, buang najis tersebut dan cuci tempat yang kotor dengan sabun dan air bersih sehingga hilang bau dan warnyanya. Lepas tu, ambil CUKA, tidak kesahlah cuka buatan china ka, thai ke, jenama mahal atau murah, yang penting cuka. Semburkan cuka tadi di tempat yang sudah di bersihkan.

Kemudian, belai kucing anda dan bermain dengannya..ini bertujuan supaya tahap angin dalam badan korang tu menurun gara-gara terhidu bau najis yang 'wangi'..tapi jangan heran kalau aku cakap, kucing tu akan ikut kemahuan kita.,contoh bila kita panggil dia datang, bila kita suruh pergi, dia blaahhh

Sekiranya anda ingin kucing tadi berak di toilet, calitkan sedikit pada tepi mangkuk tandas or lantai tandas or mana2 la ikut suka suki..pastikan tempat itu kurang 'traffic'..Kemudian anda perhatikan jika dia hendak membuang lagi, bawa kucing tu ke tempat yang sudah dicalitkan sambil sapu2 belakang atas bontot dia sebelah ekor,.tanda ko nak bagi dia berak situ. Insyaallah dia akan mula berak dalam tandas.

Bagi yang menggunakan litterbox pula, pastikan ia diletak dikawasan yang tersorok dan letak najisnya dalam litterbox tadi,. alaskan dengan carpet atau sebarang kain..kalau mau jimat guna saja newspaper yang terbuang..ini bertujuan supaya kawasan tidak kotor sebab kucing tu akan kais2 'tanah tiruan' dalam box tuh..

Selamat mencuba!!

CARA MENJAGA CONTACT LENS

Dulu-dulu, ada yang bertanya pada saya, saya ni pakai contact lens ke. Maklumlah biji mata hitam saya kelihatan besar jika dilihat secara real. Sebenarnya saya tak pernah pakai contact lens pun, tapi saya pernah tanya kawan saya bagaimana cara memakainya serta cara penjagaan contact lens. Kiranya tanya awal-awal ni sebagai persediaan kepada saya sebelum berjinak-jinak dalam dunia contact lens lah kan. Apa kata korang tengok tips di bawah ye. Manalah tau dapat menjadi inspirasi korang.

1. Mengetahui ciri-ciri contact lens : Water content, size, expired date, actual colour dan lain-lain.

2. Untuk lens yang baru, jangan terus pakai lens tu pada mata. Rendam lens tu dulu dalam lens solution selama 4 jam. Saya syorkan korang beli lens solution jenis multipurpose kerana ia boleh cuci lens serta basuh casing.

3. Setiap kali nak guna casing lens untuk simpan contact lens, pastikan yang korang sudah cuci dulu casing tu dengan lens solution. JANGAN BASUH DENGAN AIR PAIP - sebab takut dalam air paip ada bakteria dan kuman. Tangan pun mesti kena bersih juga sebelum pegang casing lens. Casing lens kena tukar selepas 3 bulan. 

4. Pemilihan lens, jika mata gelap maka pakailah lens yang berwarna terang. Jika mata kurang gelap, maka pakailah lens yang berwarna gelap. Nanti barulah nampak yang korang memang pakai lens, bukan macam mata saya. Jika nak mata nampak natural, pilihlah lens yang ada black ring kelilingnya. Makin tebal, makin natural.

5. Jangan tukar-tukar pakai lens kiri dan kanan. Kalau dah pakai lens tu di bahagian kanan, maka nanti bila nak pakai semula pastikan lens tu dipakai di mata bahagian kanan juga, dan sebaliknya. Jangan kongsi lens dengan kawan-kawan tau!

6. Jangan sesekali tidur dengan lens, nanti lens keras dalam mata. Boleh buta tau! Bahaya!

7. Pakai lens dahulu sebelum make-up.

8. Jika nak pakai ubat mata, seeloknya tak pakai lens dahulu sebelum titiskan ubat mata. Kalau korang pandai, ketepikan lens yang dipakai sebelum titiskan ubat mata.

9. Jika duduk di dalam air cond, sentiasalah bawa ubat mata untuk tak nak bagi mata kering. Jika korang pakai lens dalam keadaan mata kering, sangat bahaya.

10. Jangan pergi ke tempat terlalu panas, takut lens cair sebab lens ni plastik dan begitu sensitif dengan tempat kering dan panas.

SECURITY CODES (PART 3)

The Mobile Code Security Stack

Mobile Security - Application Layer

The application tier resides at the top of the mobile security stack and is the layer that the end user directly interfaces with. The application layer is identified by running processes that utilize application programming interfaces provided by the operating system layer as an entry point into the rest of the stack.

Application layer security flaws generally result from coding flaws in applications that are either shipped with or installed onto a mobile device after deployment. These flaws come in classes that are similar to the personal computing area. Buffer overflows, insecure storage of sensitive data, improper cryptographic algorithms, hardcoded passwords, and backdoored applications are only a sample set of application layer flaw classes. The result of exploitation of application layer security flaws can range from elevated operating system privilege to exfiltration of sensitive data.

Mobile Security - Operating System Layer

The second tier in the mobile code security stack is the operating system layer. This layer corresponds to the software running on a device that allows communications between the hardware and the application tiers. The operating system is periodically updated with feature enhancements, patches, and security fixes which may or may not coincide with patches made to the firmware by the physical handset manufacturer. The operating system provides access to its resources via the publishing of application programming interfaces. These resources are available to be consumed by the application layer as it is the only layer higher in the stack than the operating system itself. Simultaneously, the operating system communicates with the hardware/firmware to run processes and pass data to and from the device.

Operating system flaws are a very common flaw type and currently tend to be the target of choice for attackers that wish to have a high impact. If an operating flaw is discovered, the entire install base of that particular operating system revision will likely be vulnerable. It is at this layer, and above, where software is the overriding enforcement mechanism for security. Specifically due to the fact that software is relied upon, the operating system, and the application layer above, is the most common location where security flaws are discovered.

Mobile Security - Hardware Layer

As we move up the stack to the third tier of the mobile code security stack, we are moving into the realm of a physical unit that is typically under the direct control of an end user. The hardware layer is identified by the individual end user premise equipment, generally in the form of a smartphone or tablet style mobile device. The hardware layer is accessible to the operating system allowing for direct control of the physical components of the unit. This hardware is generally called the “firmware” and is upgraded by the physical manufacturer of the handset and occasionally delivered by proxy through the phone carrier. Security flaws or vulnerabilities discovered at this layer typically affect all end users who use a particular piece of hardware or individual hardware component. If a hardware flaw is discovered in a single manufacturer’s device, it is more than likely that all hardware revisions using that similar design and/or chip will be effected as well.

Mobile Security - Infrastructure Layer

The infrastructure layer is the lowest and thus most supportive layer of the mobile code security stack. This layer is the foundation that supports all of the other tiers of the model. The majority of the functional components at this layer are owned and operated by a mobile carrier or infrastructure provider; however integration into the handset occurs as data is transmitted from this tier upward.

Cellular voice and data carriers operate the infrastructure that carries all data and voice communications from end point to end point. The security of components at this level typically encompasses the protocols in use by the carriers and infrastructure providers themselves. Examples of such protocols include code division multiple access protocol (CDMA), global system for mobile communications (GSM), global positions systems (GPS), short messaging systems (SMS), and multimedia messaging systems (MMS). Due to the low foundational nature of this particular security tier, flaws or vulnerabilities discovered at this tier are generally effective across multiple platforms, multiple carriers, and multiple handset set providers.

SECURITY CODES (PART 2)

Improve the Security of Your Mobile Applications

Mobile App and Mobile Code Security Risks

There are 2 main categories of mobile code security risks. The category of Malicious Functionality is a list of unwanted and dangerous mobile code behaviors that are stealthily placed in a Trojan app that the user is tricked into installing. The user thinks they are installing a game or utility and instead get hidden spyware, phishing UI, or unauthorized premium dialing.

A. Malicious Functionality

1. Activity monitoring and data retrieval
2. Unauthorized dialing, SMS, and payments
3. Unauthorized network connectivity (exfiltration or command & control)
4. UI Impersonation
5. System modification (rootkit, APN proxy config)
6. Logic or Time bomb

The category of mobile security vulnerabilities are errors in design or implementation that expose the mobile device data to interception and retrieval by attackers. Mobile code security Vulnerabilities can also expose the mobile device or the cloud applications used from the device to unauthorized access.

B. Vulnerabilities

1. Sensitive data leakage (inadvertent or side channel)
2. Unsafe sensitive data storage
3. Unsafe sensitive data transmission
4. Hardcoded password/keys

SECURITY CODES (PART 1)

Hello people..today post is about security codes..what is security codes?? Security codes can control whether users can see and use certain fields. For example, you might want certain fields to appear for some users, but not others. To do this, add the security code, set what it controls, and then specify who can use the code.

To add a security code, from Manage, click Defined Fields, System Defined fields. Then click Security Rights. Click Add a New Value and enter a name for the code. The code appears on the System Defined Field: Security Rights page.

To set a security code for a user-defined field, from Manage, click Defined Fields. Click Add a New Field, choose your options,select the security rights for the field, and click Save.

To set a security code for a fund, campaign, approach, or letter, from Manage, click Funds, Approaches, Campaigns, or Letters. Click Add a Fund, Add an Approach, Add a Campaign, or Add a Letter. Add the fund, campaign, approach, or letter; choose security options, and then click Save.

After you add a security code and set what it controls, specify who can use it. You specify whether a user can see values for certain system-defined codes. System-defined codes represent specific pieces of data that the application needs to function. Although you can’t change the system fields, you can define values for most of them. So you can create codes for security and then assign those codes to user-defined fields or to Funds, Approaches, Campaigns, and Letters.

UNIFORM RESOURCE LOCATOR (URL) (PART 3)

Protocol-relative URLs

The protocol, or scheme, of a URL defines how the resource will be obtained. Two common protocols on the web are HTTP and HTTPS. For various reasons, many sites have been switching to permitting access through both the HTTP and HTTPS protocols. Each protocol has advantages and disadvantages, including for some users that one or the other protocol either does not function, or is very undesirable. When a link contains a protocol specifier it results in the browser following the link using the specified protocol regardless of the potential desires of the user. It is possible to construct valid URLs without specifying a protocol which are called protocol-relative links (PRL) or protocol-relative URLs. Using PRLs on a page permits the viewer of the page to visit new pages using whichever protocol was used to obtain the page containing the link. This supports continuing to use whichever protocol the viewer has chosen to use for obtaining the current page when accessing new pages. 

An example of a PRL is //en.wikipedia.org/wiki/Main_Page which is created by removing the protocol prefix.

List of allowed URL characters

Unreserved

May be encoded but it is not necessary

A B C D E F G H I J K L M N O P Q R S T U V W X Y Z
a b c d e f g h i j k l m n o p q r s t u v w x y z
0 1 2 3 4 5 6 7 8 9 - _ . ~

Reserved

Have to be encoded sometimes

! * ' ( ) ; : @ & = + $ , / ? % # [ ]

UNIFORM RESOURCE LOCATOR (URL) (PART 2)

Parts of a Uniform Resource Locator

The Uniform Resource Locator (URL) is a complete description of the location of a resource that is available over the net. It is composed of several parts that may be accessed by an application. These parts are illustrated in the following figure: 

The first portion (not technically part of the URL) identifies the protocol (http). This portion can specify other protocols such as https (secure http), ftp, and so on. 

The Host portion identifies the machine that runs the Web server and Web server application. Although it is not shown in the preceding picture, this portion can override the port that receives messages. Usually, there is no need to specify a port, because the port number is implied by the protocol. 

The ScriptName portion specifies the name of the Web server application. This is the application to which the Web server passes messages. 

Following the script name is the pathinfo. This identifies the destination of the message within the Web server application. Path info values may refer to directories on the host machine, the names of components that respond to specific messages, or any other mechanism the Web server application uses to divide the processing of incoming messages. 

The Query portion contains a set a named values. These values and their names are defined by the Web server application.

     URI VS URL

 The URL is a subset of the Uniform Resource Identifier (URI) defined in the HTTP standard, RFC1945. Web server applications frequently produce content from many sources where the final result does not reside in a particular location, but is created as necessary. URIs can describe resources that are not location-specific.