|
H.Brydon wrote: win-win-win. Any way you look at it, the pigs ended up the ultimate losers.
A thought for you (first came to me during the first Jurassic Park movie): Imagine you're aware you're going to die - and learn that you will be ingested, as well (or both at once, this last having a rather short lead-time).
Ravings en masse^ |
---|
"The difference between genius and stupidity is that genius has its limits." - Albert Einstein | "If you are searching for perfection in others, then you seek disappointment. If you are seek perfection in yourself, then you will find failure." - Balboos HaGadol Mar 2010 |
|
|
|
|
|
You left out an important part.
Imagine you have a choice between dying now or dying 6 months from now. Oh, and the impending death is a little more violent and painful.
I'm retired. There's a nap for that...
- Harvey
|
|
|
|
|
Maximilien wrote: burned down whole in a fire is different than butchered and BBQd
I know some cooks who couldn't make the distinction. :-p
|
|
|
|
|
I think this can be found on iphones too because I have been observing some BYOD iphones on networks reaching out to China servers. I was wondering what the heck could possibly be going on.
"Google pulls 500 apps that used the Igexin SDK
By Richard Chirgwin 23 Aug 2017 at 07:02 SHARE ?
Mobile developers, listen up: when you pick up that easy-to-use advertising API, make sure it's not snoopware.
That's the lesson, the take-out, or (god have mercy on my soul) key learning from work by security outfit Lookout, whose analysis of the Igexin advertising SDK ended with hundreds of apps returning “not found” on Google Play.
The firm found the SDK behaved badly by watching over smartphones and saving call time, calling number, and call state and sending that back to igexin.com...."
Adware API sends smartmobe data home to Chinese company • The Register[^]
|
|
|
|
|
Doesn't seem to list the apps that got whacked.
But more importantly, howdy? Wow, it's been so long since I saw you post! All well? Btw, your last.fm profile is a bit stale.
PM me your Whatsapp number if you want, can chat there
Cheers,
विक्रम
"We have already been through this, I am not going to repeat myself." - fat_boy, in a global warming thread
|
|
|
|
|
Vikram!
You know what's funny? I was thinking the other day about the conversations we used to have and about INTP stuff and I was wondering if you finished your schooling (I think you were attending at that time) but I am always busy and never followed up.
Yeah, some job hopping and I don't play as much music at work anymore so I don't use the last.fm plugins anymore.
I don't have Whatsapp. You on Facebook or Linkedin works too if we aren't connected already. You may still have my gmail account too.
|
|
|
|
|
I am on FB and Linkedin but rarely ever use them. Nothing works like chat anyway
But email is still cool. Can't find yours in my Gmail, we were probably using my Yahoo account at the time. If you can just send me a private mail using the below link, we can yap using email.
Cheers,
विक्रम
"We have already been through this, I am not going to repeat myself." - fat_boy, in a global warming thread
|
|
|
|
|
I can't figure out how to private reply. I must be missing something.
Yeah, looks like you were using yahoo as I searched the previous emails.
My email is my CP username at gmail.
|
|
|
|
|
So while I'm waiting for TFS to download a whole new branch...
I would think that the best way to manage releases is to have a single development branch (maybe short lived branches there while WIP is occurring), maybe some QA branches, whatever, and a single "main" branch. When a release is made, main is updated, then a branch for that release version is made in case hot fixes need to be made.
The idea being, the developers always work on the development branch. Easy-peasy.
But no. Here, we have different developer branches for every release. And I because I keep VS solutions with projects pulled from here and there and the SLN is not version controlled (that's a whole other issue as to why, let's just say the SLN files everyone else uses are so bloated with projects, and the equipment is so archaic, that it takes 30 seconds for Visual Studio simply to figure out that there are no changes to 100 projects...)
Anyways, I now have to remap the projects in my custom solutions to new "developer" branch folders (granted, that's a problem I can mitigate.)
And of course, what's worse is, I was informed Monday, "oh, we forgot to tell you that your work should now be checked in to the "Dev_A" branch for this, and the "Oct17" for that.
|
|
|
|
|
Never had a need for branches. More trouble than they're worth; a symptom of a broken process.
|
|
|
|
|
PIEBALDconsult wrote: More trouble than they're worth; a symptom of a broken process. Not at all. We have a trunk which is where all the development happens. When our release is ready to go we branch the code so that the latest branch is what most customers are running. We often need to get bug fixes to customers before the next release so we merge the bug fixes into the branch and then the customer can get just the bug fix. Very simple and very important.
There are two kinds of people in the world: those who can extrapolate from incomplete data.
There are only 10 types of people in the world, those who understand binary and those who don't.
|
|
|
|
|
Trunk should always be the current production release.
A branch should always be used for ongoing work.
Testing can be done from the branch code.
When the code is ready, it should be merged back to trunk for release.
Trunk should always be the current production release.
Otherwise your trunk (released code) gets contaminated.
|
|
|
|
|
Not how we do it and it works fine for us. To each their own.
There are two kinds of people in the world: those who can extrapolate from incomplete data.
There are only 10 types of people in the world, those who understand binary and those who don't.
|
|
|
|
|
Yes, definitely, there are many processes that work for different companies.
The interesting thing is that I thought I was agreeing with you. Seriously.
Whatever works, works best.
|
|
|
|
|
Marc Clifton wrote: different developer branches for every release
I simple shared disk, with a couple of subdirectories, with nightly backups, for all developers would be much better!!
OK seriously your suggestion is the way to go, and this is what big G and many others do: one dev branch for all. Short lived branches (call them "stabilisation branches", "release branches" etc) during release periods. This is to allow the majority of devs to keep doing their job. Hot-fixes are done on the temporary branch and ported to master after release. Never the other way.
... such stuff as dreams are made on
|
|
|
|
|
megaadam wrote: to master after release Master is referred to as trunk.
There are two kinds of people in the world: those who can extrapolate from incomplete data.
There are only 10 types of people in the world, those who understand binary and those who don't.
|
|
|
|
|
Well, it's a damn sight better than popsicle sticks!
#SupportHeForShe
Government can give you nothing but what it takes from somebody else. A government big enough to give you everything you want is big enough to take everything you've got, including your freedom.-Ezra Taft Benson
You must accept 1 of 2 basic premises: Either we are alone in the universe or we are not alone. Either way, the implications are staggering!-Wernher von Braun
|
|
|
|
|
This GIT branching model seems to be very popular A successful Git branching model » nvie.com[^]
For now we like to keep things simple with only a Development and Master branch, for "dangerous" things separate branches can be created as needed.
|
|
|
|
|
As much as I hate git (Give me file locking any day of the week) That model does work well. I advocate a GUI for git because the command line is most cryptic mumbo jumbo I've come across. GitKraken is my current favorite.
But to the original post, you are not alone, part of our source is on subVersion and the group that controls the release of that code does something similar. You make changes on the trunk and then they call a lock period on the trunk make a branch and use the branch as the release.
|
|
|
|
|
I agree, using a GUI for GIT makes life easier, we are using TortoiseGIT. But in some situations you can't avoid the GIT command line, recently I had to port our GIT repository from an Open BSD server (brrrrr) to a more manageable Windows 10 server running GITEA.
Read the horror story here: Migrate from SSH · Issue #1635 · go-gitea/gitea · GitHub[^]
Don't get the impression that GITEA is a bad choice, it works fantastic and we are very pleased with it !
|
|
|
|
|
This cartoon: UserFriendly[^] got me thinking: 36 years ago this month, the PC was released to the world for the first time.
I was in the industry when it happened, and it didn't really make a splash immediately, but IBM made some huge mistakes back then: they made it extensible, expandable, and ludicrously expensive.
Seriously: the basic usable machine (64K RAM, one off 160KB floppy, monochrome text-only monitor, and a keyboard) was priced at around US$3,000. A top of the range model with CGA monitor (16 colours text, 320x200 graphics in any four colours of your choice from the available 16, and a printer) was US$4,500.
You could buy expansion cards to get more RAM - up to 640K! Two floppies!
You could swap out the 4.77MHz processor for a slightly faster working (but same clock speed) V20 one, or buy a floating point processor and plug that in!
So clones appeared. And boy, have they progressed! There are (from what I see on t'interwebs) well over 2 billion PC's in existence and working today. And every single one of them is thousands of times more powerful than the computers that got man to the moon and back in 1969.
We - nearly all of us - owe our whole job to that tank of a PC (heavy? Nah - the keyboard alone weighed in at only 6lb) and I've been coding on or for the damn things for well over thirty years.
Perhaps August 12th should be a worldwide public holiday?
[edit]CGA, not EGA! [/edit]
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
AntiTwitter: @DalekDave is now a follower!
modified 23-Aug-17 8:26am.
|
|
|
|
|
OriginalGriff wrote: (64K RAM, one off 160KB floppy, monochrome text-only monitor, and a keyboard) was priced at around US$3,000. A top of the range model with EGA monitor (16 colours text, 320x200 graphics in any four colours of your choice from the available 16, and a printer) was US$4,500.
Go ahead and take a look what a TRS-80 Model 3 or 4 would have cost. These were still typical workhorses at that time.
Edit: Model 4 came later, that still leaves us with Model 3:
1980: July - Radio Shack introduces the TRS-80 Model III, priced from US$700 to US$2500.
The user can't update the up: we update it for them (Choice in the CP poll)
|
|
|
|
|
CodeWraith wrote: TRS-80
10 PRINT "Hello Adam!"
RUN
My first kiss!
... such stuff as dreams are made on
|
|
|
|
|
Yes, for me as well. Had a little trouble with the parents and fled to a shopping mall where I found a freshly unboxed TRS-80 (Model I), turned on and the manual lying in front of it.
The user can't update the up: we update it for them (Choice in the CP poll)
|
|
|
|
|
Or if you were a bit more advanced, add
20 GOTO 10
|
|
|
|