Android Studio Shortcuts

Add unimplemented methods: CTRL + I

Override methods: CTRL + O

Format code: CTRL + ALT + L

Show project: ALT + 1

Show logcat: ALT + 6

Hide project – logcat: SHIFT + ESC

Build: CTRL + F9

Build and Run: CTRL + F10

Collapse all: CTRL + SHIFT + NumPad +

Expand all: CTRL + SHIFT + NumPad –

Find and replace: CTRL + R

Find: CTRL + F

Advertisements
Posted in IT learning | Leave a comment

A practical security guide for web developers

The intended audience

Security issues happen for two reasons –

  1. Developers who have just started and cannot really tell a difference between using MD5 or bcrypt.
  2. Developers who know stuff but forget/ignore them.

Our detailed explanations should help the first type while we hope our checklist helps the second one create more secure systems. This is by no means a comprehensive guide, it just covers stuff based on the most common issues we have discovered in the past.

Contents

  1. The Security Checklist
  2. What can go wrong?
  3. Securely transporting stuff: HTTPS explained
  4. I am who I say I am: Authentication
    4.1 Form based authentication
    4.2 Basic authentication
    4.3 One is not enough, 2 factor, 3 factor, ….
    4.4 Why use insecure text messages? Introducing HOTP & TOTP
    4.5 Handling password resets
  5. What am I allowed to do?: Authorization
    5.1 Token based Authorization
    5.2 OAuth & OAuth2
    5.3 JWT
  6. Trust no one: User Inputs are evil
    6.1 Sanitizing Inputs
    6.2 Sanitizing Outputs
    6.3 Cross Site Scripting
    6.4 Injection Attacks
    6.5 User uploads
    6.6 Tamper-proof user inputs
  7. Plaintext != Encoding != Encryption != Hashing
    7.1 Common encoding schemes
    7.2 Encyption
    7.3 Hashing & One way functions
    7.4 Hashing speeds cheatsheet
  8. dadada, 123456, cute@123: Passwords
    8.1 Password policies
    8.2 Storing passwords
    8.3 Life without passwords
  9. Public Key Cryptography
  10. Remember me, please: Handling Sessions
    10.1 Where to save state?
    10.2 Invalidating sessions
    10.3 Cookie monster & you
  11. Fixing security, one header at a time
    11.1 Secure web headers
    11.2 Data integrity check for 3rd party code
    11.3 Certificate Pinning
  12. Configuration mistakes
    12.0 Provisoning in cloud: Ports, Shodan & AWS
    12.1 Honey, you left the debug mode on
    12.2 Logging (or not logging)
    12.3 Monitoring
    12.4 Principle of least privilege
    12.5 Rate limiting & Captchas
    12.6 Storing project secrets and passwords in a file
    12.7 DNS: Of subdomains and forgotten pet-projects
    12.7 Patching & Updates
  13. When the bad guys arrive: Attacks
    13.1 Clickjacking
    13.2 Cross Site Request Forgery
    13.3 Denial of Service
    13.4 Server Side Request Forgery
  14. Stats about vulnerabilities discovered in Internet Companies
  15. On reinventing the wheel, and making it square
    15.1 Security libraries and packages for Python
    15.2 Security libraries and packages for Node/JS
    15.3 Learning resources
  16. Maintaining a good security hygiene
  17. Security Vs Usability
  18. Back to Square 1: The Security Checklist explained

 

taken from : https://github.com/FallibleInc/security-guide-for-developers

| Leave a comment

2016

Welcome to 2016 guys;

I  congratulate to all my friends and colleagues Happy New Year 2016. I hope this year will provide a new experience, new opportunity and new resolution for you.

In this year, I still confused as to what the resolution will I do because My resolution 2015 is  not line with expectations.

I have read Mark Resolution; seems admirable build such like Jarvis; When I was college, I ever thought to build my own Jarvis. I am using C# and microphone to  detect my sound and perform the command like I told him.

But  it is not truly AI because I need to apply the command to a text file. Where I use a text file as a dictionary. So is not AI like Jarvis, if Mark builds an AI that actually it; it was awesome.

And for my resolution in 2016 still has not found. Perhaps I need to ponder while.

 

 

| 2 Comments

Watch, The Joy of debugging

Today I learn from one developer about what is bugs and when it come from. Her name is Laurent Bossavit, just shocking his job was a public servant for France Government  or PNS in Indonesia :).

First He believes every code have two part, white and black like yin and yang (two different sides). Every code you write has a dark side, that dark side was a bug :))

He has nice theories:

  1. Write code, putting bugs in it
  2.  Remove the bugs
  3. Profit

But in real, every code not realizes put bugs in code. In my experience, I am always difficult to found bugs after finish the apps, moreover if the apps used a library or module was coded by another developer.

And If Bugs occur, programmer always blame processor or computer managing in a first place :).

The point was Laurent gives is

“Bugs start as bugs in the brain”.

So every bug in our software, always come from mistakes of a developer.

From that point we can see the first problem we must solve are our brain. We can solve our brain by understanding our brain, He suggest us to read Thinking Fast and Slow by Daniel Kahneman. I am still reading it, although it’s really hard to understand. The book talk about 2 system of our brain (fast thinking and slow thinking). I recommendation you read that book too.

After we understand the system we will reduce our false or bugs in our program. The second step is debugging our apps.

Every question comes from developer after debugging are:

  1. History (How things got the way they are)
    1. How can the value of life on even though no variable has it
  2. Models (Explanations)
  3. Beliefs, hypotheses

But in software development process has a myth what makes programmer not test their code.

71roecKsIWL

But obviously every programmer should test their code. Because when they didn’t test the code, it will come bias just hypothesis no proof it. When we debugging our code often, we can realize the heart of the bug come from.

 

 

| Leave a comment

Waiting

The most boring activities I think was waiting, waiting for a  bus, waiting for person wait to take off and  waiting  for the other.

This time I am waiting for someone, I wait from 4.00 pm until this time, they still not appear. We plan to dinner in Johnny cow Steak and watch Boruto in Blitz. Are you familiar with Boruto ??

All people maybe know naruto at least they ever heard it, Naruto now was mature and have two children one girl and one boy. A boy named as Boruto and A girl named as Himawari. The mother of two children is Hinata…

You must be not to shocked, Hinata loves Naruto from they were child, I have heard someone says love was eternally maybe in Anime love still love. They married, Naruto is Hokage and they have children are their life was done ?? Happy ever Not yet.

This movie tell us in every family have a conflict moreover if his or her parent is busy, Hokage is the busy person in Konoha. We remember when Naruto was a child, he was so lonely because he don’t have anyone. Now Boruto was so lonely too, not because lonely but his parent so busy and forget to play or to give a warm kiss to Boruto.

He feels lonely in the middle of Konoha crowd, So he make Naruto focus in him with make trouble in Konoha. He make new Akatsuki and make him as a leader. Their plan is to destroy Konoha from land, sea and air. Boruto has 3 special forces to succeed  of plan. The special forces is KOPASSUS, Den Bravo, and Pasikbraka. Kopassus has powers to infiltrate enemy military power with byakugan, sharingan and hipnotis..while Den Brav0 has edo tensei power inheritable from Kapten Kid who has BlackSiber Sword. And what Pasikbraka do this time, Oh Paskibraka do was to flagsip the flag and to watch the battle of Konoha.

And the battle was begin, KOPASSUS enter the Konoha gate after kill fifty thousand Anbu with Anoa Tank..Maybe this time Anoa still useful although Anoa made Indonesia :))

to be continued…..

| Leave a comment

How to Work with Software Engineers

1. Absorb praise

As a PM, expect your successes to be recognized. Understand that executives will often attempt to spray accolades across the entire team. You must be vigilant: you are the one who is being celebrated, and you are the one who must take all of the glory. Credit is career currency, and you’re polishing your own LinkedIn profile, not theirs. Step up you ninja star, take the spotlight and bathe in the attention.

2. Deflect blame

Occasionally something will go wrong. In software development, the thing that goes wrong is usually software. When software fails, a software developer is to blame. That’s just logical. Make sure to redirect the accusations when they’re aimed at you, and to preemptively sow blame whenever possible. Always remember: there is no “we” in me.

3. Don’t bother with the details

Frivolous little technical details are for the engineers, and you have much better things to be doing. Like ideating. Comprehension only leads to disappointment and fosters a so-called “rational” view of what’s possible. You can’t change the world if you know what’s hard and what’s easy. Avoid minutiae at all costs. Anything you imagine can be done in ten lines of code. It hardly matters which ten.

4. Involve them late

Software engineers write code, that’s what they do. They’re always fretting about how stuff is distracting them from their hacking. So why would you waste their time involving them in a project before it’s ready for coding? You don’t see a bunch of construction workers kicking back in an architect’s office. Bring them in once all of the strategizing and synergizing is done and all that’s left is the programming.

5. Add process

The best way to demonstrate your value to the team is by introducing process. Rules grease the wheels of progress. Look for opportunities to schedule update meetings, daily briefings, and all-day reviews. Keep your engineers productive by requiring them to fill out tracking spreadsheets, status reports, and cross-functional executive update emails. If you don’t do it, nobody will. Get going: those voicemails aren’t going to “touch base” by themselves!

6. Never tell the reasons

Engineers are highly analytical, which means they take a less-sophisticated approach to decision-making that often relies on “supporting data” or “rationales” rather than vision and blue sky thinking. Maintaining an air of mystery when decisions are made will keep them on their toes. They’ll complain regardless, there’s no reason to give them specific things to gripe about.

7. Commit for them

Your job as the product manager is to make assurances on behalf of your team. Leadership means setting the bar high and challenging everyone to teleport over it. Show your ambition by committing to project schedules without consulting your team. Being held accountable to somebody else’s promises builds character and brings out the best in people. Think of JFK. He picked a totally random date to land on the moon and NASA beat it, claiming the planet’s vast mineral reserves for Standard Oil.

8. Interrupt at any time

You’re a busy knowledge worker, and the last thing you need is to wait for an engineer to finish their current task. You need it ASAP (pronounced “AY-sap”). Whatever an engineer is working on is less important than what you need right now. Feel free to interrupt them at any time. Chat windows and phone calls can be effective, but nothing beats the good old shoulder tap for impact. What if they’re working on something you asked them to do an hour ago? No problem! This will serve as a good lesson in prioritization.

9. Be ambiguous

There are few things more dangerous to your career than being proven wrong. Ensure this never happens by aiming to be as vague and imprecise as possible. Feel free to change your mind at will. If you take every position imaginable, by definition you were right. Don’t record anything in writing, or better yet make documents so wordy and tedious nobody will bother reading them.

10. They’re always lying

Engineers will sometimes say something is “impossible.” They’re lying. Nothing in engineering is impossible if you set your mind to it. The Wright Brothers never thought that flying across the Atlantic was impossible! Assume a software engineer is always deceiving you and act accordingly. So when you hear terms like “technical debt” or “working from home,” you’ll be ready to call their bluff.

There you have it. My Ten-Step Plan for Working With Engineers. Print this out and hang it in your workspace (consider keeping it hidden from view). If you follow my plan, you too can become a great product manager (if not one of the three greatest[3]). It’s that simple.

*note: this post just taken from kennethnorton website, if you want to read original post you can read from that.

| 1 Comment

The leadership is ??

The challenge of leadership is to be strong, but not Rude; be kind, but not weak; be bold, but not bully; be thoughtful, but not lazy; be humble, but not timid; be proud, but NOT arrogant; have humor, but not without folly, -Jim Rohn

| Leave a comment