RSS

Git : How to configure Author name in git

Here are the simple steps to configure your author name in Git.

Configure the Name in Git to avoid unknown in author name

1. Click tools

2. Go to options

3. Click General

4. Insert your name and ep email id an save it

 

git

 

If you want to follow command line :
$ git config –global user.name "Aseem Jain"
$ git config –global user.email mail@premseem.com

 
Leave a comment

Posted by on April 14, 2015 in git

 

Tags:

The Progressive Reveal

I like to provide learners with progressive revelations. This instructional strategy involves slowly revealing information, especially visual information.

I like to start with one part of a visual concept and then build on it. I show one part of a diagram and then slowly complete it. For example, picture a simple hierarchical diagram where only the box at the top is visible. Then as you discuss, you show the next row of boxes, discuss some more and show the next and so on. This can work well interactively too, where the learner reveals the diagram through certain actions.

progressive-reveal

 

It’s Good for Working Memory

Why is this a good way to present information? Because working memory, the online portion of our brain, is limited in capacity. Most people just can’t hold too much more than around four bits of information in working memory at one time. I know they used to say it was seven bits of information, plus or minus two. But the number seems to be shrinking.

By progressively building on a previous concept or rule or principle, we give learners time to retrieve information from long-term storage, so they can comprehend the initial information. Once the initial information is firmly understood, there’s a much better chance they will comprehend the next bit of information than if we sped ahead from the start.

It’s Good for Encoding Information

A progressive build is also a good way to help learners encode information into long-term memory. When a learner holds information associated with the instruction in working memory, it helps the instruction make sense and gives it meaning. When information is meaningful, it’s connected to one’s personal network of knowledge. Well-connected information is more likely to get encoded “deeply” into long-term memory.

A Simple Approach

Sometimes I’ll use the most basic approach to create a progressive revelation, without even creating a Flash animation. Using one of the PowerPoint based authoring tools, I just place a rectangle over a portion of the graphic that I want to progressively reveal. The rectangle is the same color as the background. Over time or over several screens, whichever works best for the learning situation, I’ll slowly move the rectangle away so that it progressively reveals the visual beneath. What could be easier? I don’t want everyone to know how easy it is to do this, so I’m just telling you.

 
Leave a comment

Posted by on April 14, 2015 in Computers, UX - Visual Design

 

Tags: , ,

Hard work Vs Smart work

Do not get too busy in doing hard work, have some scope to look around for the way to incorporate smart work ;-)

to busy

 
Leave a comment

Posted by on March 26, 2015 in Leadership, Management

 

Tags: ,

Git : How to remove Git tag using source tree

To remove a git tag :
1. select any commit and select tag or right click on tag name and say remove
2. From the tag box select the tag name from drop down.
3. pick remove tag from remove
4. click on remove tag

gitRemoveTag

 
Leave a comment

Posted by on March 25, 2015 in Uncategorized

 

Git : How to create a tag in git using source tree

Tag creation in GIT using source tree in simple steps :
1. select a commit to be tagged
2. right click and pick tag option
3. Provide tag name (lable)
4. Click add tag and push it to remote

gitTag

 

In case if you want to do the same using command prompt / shell the fire below commands

git clone <repo-address>

 

git tag -l

 

git checkout <tag-name>

 

git branch -D master

 

git checkout -b master

 
Leave a comment

Posted by on March 25, 2015 in git

 

Tags: ,

Dear Software Engineers, your job is not to write code!

Dear Software Engineers,

Your job is not to write code.

I know. You think you were hired to write code. In fact, your entire interview process centered around how well you could write code. And I’m sure you do it really well.

But it’s not your job.

Your job is to improve our product for our users. If you want to get technical about it, your job is to improve our product for our users in a way that improves the key metrics of the company. But honestly, you don’t always have a lot of control over that second bit. You do, however, have an enormous amount of control over the first bit!

Of course, if you want to do your job well, it does mean that you may have to change some of your current behaviors.

For one thing, you need to make sure that the code you write (writing code is still one of the main things you will do when doing your job, by the way) runs the way it should, even on users’ machines.

Did you know that our users probably don’t have brand new MacBook Airs with giant Thunderbolt monitors set at the highest resolution possible and running the latest version of Chrome? I checked. A lot of them have Internet Explorer on 4 year old laptops, so sometimes things you build don’t work right on their machines. They’re still our users, and it’s still your job to improve the product for them, so please make sure that the code you wrote works in a reasonable number of environments.

In fact, you’re going to need to make sure that the code you wrote runs in production, in general. I don’t really care if your code runs locally. If your code just runs locally, then my only option is to sell your computer so that our users can use our software, and that really doesn’t scale.

So, to avoid that, you need to check your changes in production. Every time. Remember, your job is not just to ship something. It’s to ship something that improves our product for our customers. You can’t know it will do that unless you check that it runs in the way it’s supposed to.

Of course, in order to check your changes in production, you’re going to need to make sure that your code actually gets merged and pushed into production. I mean, you can’t really check your changes in production if you just let them sit unpushed for hours or days. Push your code. Get it into production. Then run it and check it.

This is obviously harder to do if you’re in an environment where you can’t do continuous deployment, but the theory still holds. When your code gets into production, whenever that is, you’re still responsible for it. Make sure that it’s doing what it ought to be doing – which is make the product better for users.

Another thing to remember is that sometimes users do surprising things, which means that it’s not enough just to test that your code works under perfect conditions. You need to make sure that it does something reasonable even in error cases and zero data states and when the user does something you might not expect, like use the back button or make two accounts by mistake.

This is hard. It means you’ll have to spend time thinking about the different things our users might do. But it’s an important part of your job, because it will vastly improve the product for our users if they aren’t constantly finding bugs or edge cases or dead ends.

There’s one more important part to your job. You need to make sure that we can measure whether we’re all doing our jobs well. That means adding metrics and analytics so that we can test the effects of our changes. If you expect the code you are writing to improve user engagement (by improving the user experience in some key way), then you need to have a way to learn whether or not you succeeded. How else will you know if your job is done? Because, as I’ve mentioned, your job isn’t done until you’ve improved the product for our users.

I know what you’re thinking. This will all take so long! I’ll be so much less effective!

This isn’t true. You’ll be far more effective because you will actually be doing your job. If you get hassled for writing less code, that’s a failure of management, and I apologize for it. We need to spend less time demanding that you write features and more time asking you to improve our product for our users. If we’re not doing that, I strongly suggest you ask us to. If we still refuse, you should leave and find an environment that lets you do your job. Which, not to beat a dead horse, is to make the product better for our users.

Please don’t feel like I’m picking on you. You’re not the only one who should be doing this job. It is all of our jobs to make the product better for our users. It is my job as a PM and UX Designer and Manager to understand our users well enough that I can help you know how to improve the product for them. It is the CEO’s job to find a strategy that allows us to make money by improving the product for our users.

No matter what our job titles, our jobs are all the same — to make the product better for our users. Every day. So let’s do that.

Thank you,

Your Product Manager

Dear Engineers, your job is not to write code! – Tweet This

*This post originally appeared on Medium*

 
Leave a comment

Posted by on February 24, 2015 in Best Practice, Computers, Literature

 

Tags: ,

What is petty cash?

Petty cash is a small amount of discretionary funds in the form of cash used for expenditures where it is not sensible to make any disbursement by cheque, because of the inconvenience and costs of writing, signing, and then cashing the cheque.

Image result for petty cash

The most common way of accounting for petty cash expenditures is to use the imprest system. The initial fund would be created by issuing a cheque for the desired amount. An amount of $100 would typically be sufficient for most small business needs as the expenses to be covered are for small amounts. The bookkeeping entry for this initial fund would be to debit Petty Cash and credit bank account.

As expenditures are made, the custodian of the fund will reimburse employees and receive a petty cash voucher with a receipt/invoice attached in return. At any given time, the total of cash on hand plus reimbursed vouchers must equal the original fund.

When the fund gets low, e.g. $20 remaining, the custodian (a bookkeeper or a member of the administration staff) requests a top up and submits the vouchers for reimbursement. Assuming the vouchers add up to $80, an $80 top up cheque is issued and an $80 debit towards office expenses is recorded. Once the cheque is cashed, the custodian again has cash at the original amount of $100.

 
Leave a comment

Posted by on February 21, 2015 in Accounts

 

Tags: ,

 
Follow

Get every new post delivered to your Inbox.

Join 1,161 other followers

%d bloggers like this: