Find out what you, or someone on your team, did on the last working day
github.com
github.com
I understand many don't agree with this, but this is my preference / opinion.
Of course, the reason this is happening is that there's a bunch of people now writing command line tools in JavaScript because that's what they use and know. Just like in the past (and now) there were a bunch of people doing it in Perl, Ruby, etc.
It's definitely not very UNIX-y in its ethos, but I can understand why it happens.
Node is meant to be used async, which makes simple dev tools like looping over a bunch of .zips and extracting them a total pain. Pretty much every library or method of doing something in node.js is going to lead back to promises, and the second that happens your entire app becomes promises. Its massive overkill for most small dev tools.
> Command line tools are minimal and should be usable on bare-bones systems
I disagree. I run a very graphical desktop, but nonetheless have a strong preference towards CLI tools when they are for relatively simple tasks.
I think this tool makes sense as a CLI tool rather than as a non-CLI tool. Given that, the question comes down to "given that this will be a CLI tool, what language should the author have used?". In almost all cases, unless portability is a string concern, this comes down to personal preference.
> By default the script searches only in the current directory or one level deep. If you want to increase that, use the -m switch. $ git standup -m 3
hg log --rev "date(yesterday)" --template "{shortest(node, 6)} - {desc|firstline} ({date|age}) <{author|person}>\n"
This shows off both revsets (the language parsed by the --rev option) and templates (the language parsed by the --template option). The revset can be modified into "date(yesterday) and user(jordi)" to limit it to only a particular user.
As it stands, this revset+template combination won't colourise the output. For that we need to add labels to the template:
hg log -r "date(yesterday)" -T "{label('changeset.{phase}', shortest(node, 6))} - {label('log.summary', desc|firstline)} ({label('log.date', date|age)}) <{label('log.user', author|person)}>\n"
At this length, it starts to look unwieldy, but it should go into your hgrc anyway, where you can easily split it into multiple lines without having to worry about shell quoting. Here are more details about the general method:
http://jordi.inversethought.com/blog/customising-mercurial-l...
> curl -L https://raw.githubusercontent.com/kamranahmedse/git-standup/... | sudo sh
JSP shell committed into Git, self-approved, and queued for deployment
nice. this shit again
This outlines a POC for detecting whether your script is being downloaded or piped into Bash. Beware.
Also, the attacker can push an update if they can successfully guess the window between you reviewing a file and you installing a file. Not nearly as reliable as that POC, but hardly impossible.
Best to avoid building bad habits. Perhaps worthwhile to build good ones - even when it's "safe" to skip.
You are taking a leap of faith anytime you install something however you do it. The problem with the CPS seems to me that it's much easier for you to correctly trust the originator of the content, but have the content hijacked by a 3rd malicious party.
It seems like a great system, that isn't used regularly by people in my circle.
I'd say 99.999% of the time someone runs an installer script to install something, they don't read it first. And if you're not reading the script first, then there's no benefit whatsoever to downloading it prior to executing, as opposed to just executing directly. The only reason to say "don't pipe into sh" is if you're saying "review the installer script 100% of the time before executing it", which, honestly, is advice nobody's going to follow.
Sure, no server has ever been compromised and his binaries replaced... The good old pgp signatures, circle of trusts, etc are not for show. Eck, it's not even served from github.com but from a random proxy
Anyone who's willing to read the script first, or verify PGP keys, or whatnot, is perfectly capable of doing so even if the instructions tell you to pipe to bash. But the overwhelming majority of people don't do that.
git log --author="tlbonnette@gmail.com" --since=1.days
You can of course tweak the way that git log outputs too, to make it more readable.
Something like:
git log --pretty=format:%Cred%h%Creset -%C(yellow)%d%Creset %s %Cgreen(%cr) %C(bold blue)<%an>%Creset --abbrev-commit
can make it quite pretty.
His examples seem …prolific. I mildly hope his tool outputs something like "No commits for this author; must be out shaving the yaks" on the days when someone has nothing to commit. Perhaps he is working on a nicer code base than I.
day = log --all --abbrev-commit --date-order --date=relative --since='one day ago' --stat
day-more = log --all --abbrev-commit --date-order --date=relative --since='one day ago' -p -w
weekend = log --all --abbrev-commit --date-order --date=relative --since='three days ago' --stat
weekend-more = log --all --abbrev-commit --date-order --date=relative --since='three days ago' -p -w $ tt 2017-03-21
repo1 author date
commit desc
commit desc
repo2 author date
commit desc
function tt {
local day=$1;
local d=$PWD;
local buf="";
echo $day;
cd $GR;
for i in *; do
local p=$GR/$i;
if [ -d "$p/.git" ]; then
cd "$p"; whatup $day
fi
done
cd $d;
}
function whatup {
local day="$1"
if [ "$day" = "" ]; then
day=`date +'%Y-%m-%d'`
fi
local author="$2"
if [ "$author" = "" ]; then
author="amichal"
fi
local dir=`basename $PWD`;
local msg=`git log --all --author $author --oneline --since="$day 00:00:00" --until="$day 23:59:59.999"`
if [[ ! -z "${msg// }" ]]; then
echo "$dir $author $day"
echo "$msg"
echo "----------"
fi
}Standup listing what you did kind of sucks. But also literally knowing 0 about what anyone else in the team is working on also sucks. Unless you literally just want to be handed a pile of Jira tickets by a PM and told to fix them? But that seems not a very healthy environment.
Something like this post where you dump a git log of what each person pushed could get maybe the boring part of standup automated... and then you would only need to report the non code part.. which maybe seems better?
Something more fundamentally wrong is going on if people can't assign work more than a day in advance without stepping on each other's toes.
Daily standups are simply a form of micro-managing, the scrum guys have done a colossal amount of harm to our industry.
Have you worked both remote and in person? In person you generally see people every day. Remote you do mot.
> Something more fundamentally wrong is going on if people can't assign work more than a day in advance without stepping on each other's toes.
Not always about assigning work. What if you are working on some task, and to fix a bug you need to refactor something. How do you spread that knowledge? Code review by entire team? Slack blast? Stand-up announcement? Somehow you should want to manage that..
> Daily standups are simply a form of micro-managing, the scrum guys have done a colossal amount of harm to our industry.
Scrum is a tool. It can be used well, and it can be used poorly. There are times when over-communication (what scrum tends towards) is very good. There are times when it is bad. I think remote it can be better to slightly over vs slightly under-communicate.
Leaving first employer: Sit in a windowless room with a newspaper and several other people also with feet on desks also reading newspapers, riding out 90 days of resignation notice looking forward to next job. Fully paid, needing to turn-up 4 hours per day mainly centered around lunch, which included a break and had social time with soon-to-be former-colleagues. Cannot in any way be associated with future employer during these 90 days: meetings, personal interaction, emails, visits, anything.
Edit: For those that think this doesn't sound right, think of your access to market-sensitive information, and a loyalty exists with the soon-to-be former employer. Mitigation of ourselves and the organisation.
I, and others in the windowless room were completely OK with this set-up of arrangements, as were our future employers who knew this on signing us. Not a non-complete clause in any way, simple prudence.