|
Exactly, or you would fall into the "jack of all trades, master of none" bucket.
|
|
|
|
|
I already did. 
|
|
|
|
|
At work we are gonna use Google Drive and Drop Box.... in an Android C# App! 
While Google Drive and DropBox official API both supports PCL, the crucial initial step of sign-in to the service is... lacking!
But hey, they support OAuth!
I found 2 "SimpleAuth" library. One which is lying, it installed like zillion of packages... didn't even bother go further...
And a really simple one[^]! 
2 hours later I committed a provider for DropBox, next day it happened, voila[^]!
|
|
|
|
|
Karsh Kale - Dancing at Sunset[^]
Totally a coincidence that I put on some Karsh Kale last week. I had not listened to it in quite a while. It's pretty awesome though
Karsh Kale, producer, composer, and DJ, creates electronica (mostly dance-ish) with (classical) Asian, mostly Indian, elements.
With such awesomeness what else could I do than listen again and again and make this my song of the week?
|
|
|
|
|
India has one of the most diverse and fascinating panoplies of percussion instruments in the world and he uses a drum track? By the rivers of Indus we sat down and wept!
I am not a number. I am a ... no, wait!
|
|
|
|
|
Either that or he makes heavy use of triggers
At least it's Indian percussion sounding drum tracks.
Karsh Kale is, first and foremost, I guess, a DJ
At least you're not telling me this song is actually someone else's song 
|
|
|
|
|
|
That is...
For some reason it reminded me of this guy[^]
I did find Lena[^] in the related videos though, really liked her in 2010
|
|
|
|
|
I git, we all git! 
I'm trying to work out a proper structure here for git repos and it is tres fun! We have two products, one is the container and the other the first containee, though there will probably be more. That is relatively easy and this then gets deployed to clients who are free [for a given value of free] to change some or all parts.
So we have a repo for each product and a repo for each client. The built components will then be put over to the client repos for deployment and other shenanigans.
Would anyone care to tell me how this is going to go wahoonie shaped, or do I have to wait and find out for myself?
veni bibi saltavi
|
|
|
|
|
Nagy Vilmos wrote: how this is going to go wahoonie shaped
Like Bel-Shamharoth in a Octal tutorial!
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
|
|
|
|
|
Hopefully I'll be more of Hrun then a Rincewind...
veni bibi saltavi
|
|
|
|
|
You mean practically an academic by Hub standards in that you could think without moving your lips?
I'd rather be a Ghenghiz Cohen: "Never enter an ass-kicking contest with a porcupine."
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
|
|
|
|
|
I have used Tortise SVN, cue the song I compsed 'Squwash the tortise' sung to tune Ride of The Valkarie, generally verse 2 was NSW!
|
|
|
|
|
Having used Git for a while, I can say with almost absolute certainty that that process will go all wahoonie shaped at the worst possible moment. That just seems to be the nature of Git. If it actually works, that will be a major WTF.
Git works, but it has some.... quirks.
What do you get when you cross a joke with a rhetorical question?
The metaphorical solid rear-end expulsions have impacted the metaphorical motorized bladed rotating air movement mechanism.
Do questions with multiple question marks annoy you???
|
|
|
|
|
My plan is to try and avoid as many quirks as possible using a big hammer.
veni bibi saltavi
|
|
|
|
|
Think about some merge strategies and what and where will be the "master". It isnt so clear as you may think. 
Here are some text and pics about common scenarios.
Press F1 for help or google it.
Greetings from Germany
|
|
|
|
|
That just confirms my ideas for a single repo. My real problem is that we will be releasing to client repos, If you imagine the flow is build the products in their own areas, deploy them to a client repo, that gets mods on top, which then gets deployed to their hosted servers.
It's the going from internal to client repos that is getting me, I can't see the flow yet.
veni bibi saltavi
|
|
|
|
|
The page is about branching strategies within a single repo - you typically do this much more than with SVN or TFS, the merge support is much better so don't let it put you off.
Mode this through the fact I more or less do JS work not (I've stopped scrubbing myself clean every night, like every other language you can write it well or badly. Trouble is with JS there are a lot of people writing it badly).
The flow I've seen is to have the client pull & build it's dependencies - as long as the account on the build machine has access to all repos it should be OK. In JS land this is a doddle - the package.json allows you to set up dependencies and the node package manager can be told to install these. I dare say there is a way to do something similar via nuget (not sure though). That's assuming you're willing to allow the extra time to build the products with the time instead of distributing binaries.
|
|
|
|
|
It's a lot more complinated than letting clients pull or build what they want. The best I can describe things is that we build the framework, the clients add components on top and that is then what they use. The trouble comes in that we will not be giving them our core code, it is proprietary, and we will be managing their servers; think SaaS / Hosting model.
veni bibi saltavi
|
|
|
|
|
Nagy Vilmos wrote: then gets deployed to clients who are free [for a given value of free] to change some or all parts.
Given what I've experienced, you are in for a lot of pain as soon as the first time you need to change something in the same file that the client has changed. First, they try to push a change they made, not realizing their repo is behind. They get an ugly error message. Then they try to do a pull, which probably asks them to stash their changes first. That's the first real WTF. How do you do that? If they figure that out, the next WTF is how to restore the stash. Then the third WTF is, how do I interpret this archaic <==== and >========= to understand which are my changes that I want to keep, which are not. If they get that far, then they can commit their changes and YOU have to do a pull to sync up.
It sounds like 1) you are and your clients are in for a world of pain and 2) source control is probably not the right solution to begin with. Unless you can 100% isolate allowed client changes from the repos you/they control, so in the end, you do not care one whit whether they make changes or not, and they don't have to worry about their changes being stepped on when you update the container and client-specific but not client-modifiable files.
My 2c
[edit] I would put together a bunch of scenarios you can think of and try it out, which some simple text files to simulate everything. [/edit]
Marc
|
|
|
|
|
Hi All,
My employment woes I have mentioned before...but, I went for an interview yesterday in area not too far from home. The job title was odd, I was expecting a can you solder this test. Instead I was greeted with a company that was right up my street! I got on with the Boss and the HR person very well, seemed to get on with the others I met. It all went well(?) I show them some of the stuff I worked on in the past which got the responce of 'Oooh, you can do that too...'. Just had a call from the agent that they are having a company meeting as the Boss & the HR felt I was the right fit to see what else everyone else thought...  This looks hopeful! Please.
|
|
|
|
|
Good luck in the final meters! let's hope you get it.
|
|
|
|
|
|
Good luck. Fingers, legs, toes and eyes crossed for you 
This space for rent
|
|
|
|
|
Missing : Hands, ears, hair and ankles
Find More .Net development tips at : .NET Tips
The only reason people get lost in thought is because it's unfamiliar territory.
modified 19-May-16 8:00am.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
