On August 11, 2011 01:00:22 pm kfj wrote:
> On 11 Aug., 15:09, Yuval Levy <goo...@levy.ch> wrote:
> > On August 11, 2011 05:17:41 am kfj wrote:
> > > I beg to differ. I hope it will be better, because it should be faster
> > > and crash less.
> > 
> > Will you deliver?  I rather under-promise and over-deliver than the other
> > way around.
> 
> I feel this is an unfair and suggestive question.

Neither suggestive nor unfair.  You are the one who stated that it will be 
better, quoted above.


> I am not intending to do this alone, and I don't know if it will succeed.

I do not intend to leave you alone.  Well, I will have to adjust to my 
university schedule, and there are still too many unknown regarding the 
workload and the summer.  Technically, classes and exams are September to 
April, but I still have to investigate / get a complete pictures of what I 
will do in the next three summers.

I know about the uncertainty of such a project, and this is why *my* only 
statement to the end-user would be: SAME AS BEFORE.  Because I have enough 
experience of software development to know that the worse case - that we end 
up with a learning experience and nothing more - is a real risk.


> I'm certainly
> not putting myself in a situation where I might have to 'deliver'
> something.

The statement "I hope that it will be better" is certainly putting whoever 
will participate in the venture in that situation.


> I hope my arguments are sound enough to get a few people on board.

Your arguments are sound.  It takes more than arguments to get people on 
board.  I know that at this point I can't get anybody on board simply because 
I don't have a vessel.  I know what kind of vessel I would like to build, 
thanks in part to your arguments.  I lack the time/resources to build it.


> I'm not a GUI person

I have some experiences with (G)UIs that date to the days before Windows.  I 
once designed a GUI in GEM [0] to control and visualize the process of EDM 
machines.

In more recent times I designed the UI/UX to an online trading platform, an 
investment infomation system, a portfolio advice tool.  All of them dealing 
with large amount of abstract/complex data and visualizing information and 
controls so that the target user could digest and operate them.  But I was not 
involved on the code side of things.  Oh, and I also had a short stint 
consulting on the UI of a pretty successful commercial photo app.


> I'm interested in the part that I've already been working on, mainly
> the data-carrying backend, some maths and the integration of
> collateral code. My interests are C++, python and computer language
> design, with a smattering of automatic code generation, data bases,
> DSP and image processing thrown in. And I suppose I have a reasonably
> good understanding of overall software design.

I got into Hugin because I wanted to make changes to the UI.  I've been 
dragged deeper into Hugin as-is and far away from actual UI redesign (hence 
the Qt branch rotting away).  As an MBA I found it interesting to operate 
("manage") in a non-traditional environment where the traditional incentives 
(money) and organization forms do not work.  I enjoy challenges.  So I put my 
fingers in the code as well.  From an UI-design perspective I find wxWidget's  
XRC horrible to work with.  To a point that I considered making a web-based UI 
for those functions of Hugin that I need.  I do most of my pano work on the 
command line with some glue scripts.

 
> So here you have my under-promise.

And here is mine:  I have no formal IT training - I am a Chartered Financial 
Analyst, trained as an economist with an MBA;  on the way to a JD.  I just 
happen to have extra-energy on the side and itches to scratch.  I did 
commercial software development in my youth because I found it paid more than 
selling ice creams to German tourists in Ascona.  When I found myself on the 
buy side with my own money, I ended up doing in-house software development for 
the same reason why I preferred to buy ice creams and make software back then 
in my youth.

 
> I did not find these links helpful.

...

> Is this what we have when it comes to cenceptual work and
> documentation?

I am afraid yes.  Sorry.

 
> > Isn't it you the shadow I see in the driver's seat of the bus I am
> > sitting in?   Or should I worry and get off at the next stop?
> 
> I'm not buying the bus analogy. What I have experienced in this
> discussion is that apart from you who seems to think a rewrite is a
> good idea the most enthusiastic response has been Harry's 'I'm the
> last to try to stop it.' If it turns out to be just me (once you're
> off again) it won't happen. I may do a bit of tinkering on my own if I
> have time, but I'll certainly not push it.

Well, the bus (or vessel) I am looking for is a basic Python framework to 
start tinkering with.  If you look at Hugin, this is how it started:  a basic, 
empty wxWidget/C++ shell.  I already had a basic wxPython thing working, and I 
even found access to OpenGL and displayed an interactive equirectangular 
within a primitive Python GUI.  But I know that this is the wrong way to go 
about.  I need help designing the architecture to avoid getting into spaghetti 
code territory.


> > Do you want to set up a project on Github?  I know you don't like
> > SourceForge.  It's a historical given.  Launchpad is great for tracking
> > tickets (and being able to add attachment up to 100MB and answer by email
> > helps a lot), but I don't like bzr.  We could also try tracking on Github
> > as well and see how it goes?
> 
> I'm not sure if we're there yet, and I feel I'm not competent to make
> the choice. What's wrong with mercurial?

Nothing.  It's SourceForge.  And it is the slick interface of GitHub that is 
attractive.  If they offered HgHub similar to GitHub, I'd go with HgHub.


> I thought you were all for it.

Yes, of the three major distributed source code management tools of that 
generation I prefer Mercurial.  Conceptually Git/Hg/Bzr are very similar and 
indeed they borrow heavily from each other.  Where I like Hg more is that it 
is written in Python.  When I evaluated the three, Hg had the better Windows 
and OSX integration.  Probably helped by Python.


> Since it'd be a FOSS project, we might have the repository hosted
> with bitbucket. Anything wrong with that?

Wrong? not at all.  I've just noticed that they use Hg and that they are free 
for FOSS projects.  I have no experience of Bitbucket and I don't recall why, 
back in early 2010 when I was doing my research I did not hit on that.  We 
ended up migrating to Hg in May 2010 and staying on SF.  I see on the BB 
homepage that they have been acquired by Atlassian in September 2010.  Maybe 
the change brought in by Atlassian has made them into that attractive outfit 
that they are now?


> I think we need something
> for brainstorming and structuring. Any suggestions?

My wish would be a Skype conference call.  But my notebook is down.  I am 
waiting for the replacement HDD to arrive and my workstation's A/V is 
suboptimal.

When are you going to the mountains again?

I'm heading into the kitchen now.  Treating my Canadian friends to Saltimbocca 
alla Romana.

Yuv


[0] http://en.wikipedia.org/wiki/Graphical_Environment_Manager

Attachment: signature.asc
Description: This is a digitally signed message part.

Reply via email to