FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > CentOS > CentOS

 
 
LinkBack Thread Tools
 
Old 09-15-2011, 01:42 PM
John Hodrien
 
Default Upgrade from 5.6 => 5.7

On Thu, 15 Sep 2011, Always Learning wrote:

>
> On Thu, 2011-09-15 at 05:16 -0700, Craig White wrote:
>
>
>> Gmagic/Imagick are somewhat incapable of doing graphing at all.
>
> Have you ever really looked ? What about GmagickDraw:oint and similar
> items ?

I think the risk of the KISS approach is that you tend to reimplement
everything, because everything everyone else has done is overcomplicated.

It's not that you *can't* do all this yourself, but that you're possibly
dealing with life at a layer or two lower than you might. Simply by using an
existing library (say jpgraph, but it's chosen at random) you get a load of
functionality (that gets improved over time) without having to implement any
of it yourself. You're not simply producing a graph, you're producing code
that draws a graph and then drawing a graph. Why write the code?

I much prefer other people's bugs to my own, as there's a chance they'll fix
it, or failing that, I can fix their bug and the world's a better place.

jh
_______________________________________________
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos
 
Old 09-15-2011, 01:53 PM
John Hodrien
 
Default Upgrade from 5.6 => 5.7

This whole thing has gone wildly OT, so I'll check out on this post.

On Thu, 15 Sep 2011, Always Learning wrote:

> Hopefully that is always possible - retrieving EXACTLY what was stored
> in the database. Why would one want the database to manipulate (change)
> data ? Is that a solution for lazy programming ?

In the ideal world, a database has sufficient internal intelligence to make
sure that you don't get impossible data stored. It doesn't mean you can't
have wrong data, but you at least keep the database in a sane state. Without
this intelligence, your database becomes a bucket of data, where the only
controls are in the application. A bug in the application means issues with
the validity of the database.

> Simplicity and good design makes applications fast.
>
> If an application is fast and effective, because of its design and
> simplicity, why complicate it ? A SQL View is an additional overhead
> and not needed, in my opinion, in (my) well-designed systems.

But you see database simplicity as being simple, but ignore code simplicity.
I don't get why you see them separately. I'm not saying every database you
produce should be loaded with every feature you've read about in a book. But
a constraint here and there, and a mostly normalised database isn't a bad
thing. If you're not joining tables ever, your tables are probably poorly
designed, or you're doing database work in your application. There's just a
rumbling suspicion throughout this that you don't really need a database.

>> I think with most applications like you're describing people have a
>> decision to make as to how much logic goes in the DB and how much goes
>> in the app. When you're new to it, I think you tend to put all the
>> logic in the application. As you progress I think you at the very
>> least put in controls into the database to maintain the integrity of
>> the data.
>
> As one becomes more knowledgeable and accustomed to things, one
> inevitably regards the database and applications as being integral parts
> of the same system. Efficient retrieval of stored data should be a
> paramount consideration for the good design of applications.
>
> Unsure why you mean by "at the very least put in controls into the
> database to maintain the integrity of the data."
>
> The integrity of the data can be divided into two aspects: ensuring the
> data remains constant (unaltered) while stored, which is the
> responsibility of the operation system and the database software, and
> the data's integrity from an application perspective. Junk-in always
> causes Junk-out even when using 'non-dumb' databases :-)

Thing is, that's just not true. Junk-in *can* cause junk-out, or it can cause
a runtime error and refuse to let you store the junk. I'm biased in favour of
the latter, but you're not going to get that unless you load your database
with more logic.

By all means do things your own way, nobody's going to stop you.

jh
_______________________________________________
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos
 
Old 09-15-2011, 02:01 PM
 
Default Upgrade from 5.6 => 5.7

Top note: I missed this whole thread, being on the east coast of the US,
and it came in overnight.

Always Learning wrote:
> On Thu, 2011-09-15 at 05:16 -0700, Craig White wrote:
<snip>
>> You would likely use a flash or google charts implementation these days
>> to generate graphs as there are all sorts of libraries that make this
>> dead simple.
>
> No Flash. It is a known security danger and stores, without the user's

Flash, for reports? That's like the VeryLargeCorporate website I saw a few
years ago, that had a bloody FLASH VIDEO on the search page for jobs, with
some actress (or HR person) telling me about their "hot jobs" (gee, I'm
know nothing about that field, but it's Hot, so I think I'll apply!!!)

Not good enough for Hollywood or the ad agencies, so they want to make
video for NO good reason. Style over content.
>
>> Framework is the core of any application. It's well known terminology
>> for anyone who has done software development...
>> http://en.wikipedia.org/wiki/Software_framework
>
> Untrue. The 'framework' seems like a nightmare ....

I agree. Why use a framework when you just need to know what library
functions to call.

This is, in fact, a part of my rant, which I will someday write as a
paper, on the failure of OOP (Jan, 1994: IEEE Spectrum cover, where OOP
was *literally* presented as the silver bullet to the software backlog).

In short: you want a clipping from Godzilla's toenail, and, using OOP and
frameworks, you call in Godzilla, and put a frame around his (her?)
toenail.

Looking up the word "bloatware" is left as an exercise for the reader.
<snip>
> "... Software frameworks rely on the Hollywood Principle: "Don't call
> us, we'll call you."[12] This means that the user-defined classes (for
> example, new subclasses), receive messages from the predefined framework
> classes. Developers usually handle this by implementing superclass
> abstract methods."
>
> NO THANKS. Frameworks is certainly not for me. It seems like a gigantic
> and over-complicated time-waster.

Ah, yes. About 5 years ago, I was teaching myself java, and using, um,
swing? struts? I forget, and trying to get information out of a whatsit
that controlled a button was like trying to scratch your ear by reaching
between your legs. IIRC, I had to define a bloody *global* to get info
out, which violates *every* part of OOP, and even good programming.
>
>> If you don't adopt an existing framework, then you have to create your
>> own framework as your application develops sucking an inordinate amount
>> of time and given to endless refactoring as your application evolves.
>
> Disagree. 'Keep it Simple' is my preference. Don't complicate things.

Right. Write a main line, add stubs, put library calls in stubs. Unless
you write spaghetti code, you're not talking more than, say, 100 lines of
main line. So, how's that "an inordinate amount of time" creating a
framework?
You do have to sit and think, first....
<snip>
> I have 44 years computer programming experience. I have seen enormous

Beat me - I "only" started doing it for a living in 1980 (after two years
of classes).
<snip>
mark, KISS

_______________________________________________
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos
 
Old 09-15-2011, 02:05 PM
 
Default Upgrade from 5.6 => 5.7

John Hodrien wrote:
> On Thu, 15 Sep 2011, Always Learning wrote:
>> On Thu, 2011-09-15 at 05:16 -0700, Craig White wrote:
>>
>>> Gmagic/Imagick are somewhat incapable of doing graphing at all.
>>
>> Have you ever really looked ? What about GmagickDraw:oint and similar
>> items ?
>
> I think the risk of the KISS approach is that you tend to reimplement
> everything, because everything everyone else has done is overcomplicated.

The "danger" of KISS approach? So, you endorse complex and complicated
schemes? And here I thought that the True Believers in OO asserted that
OOP was cleaner, simpler, and easier.
<snip>
mark

_______________________________________________
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos
 
Old 09-15-2011, 02:19 PM
Always Learning
 
Default Upgrade from 5.6 => 5.7

On Thu, 2011-09-15 at 14:42 +0100, John Hodrien wrote:

> I think the risk of the KISS approach is that you tend to reimplement
> everything, because everything everyone else has done is overcomplicated.

I share coding within systems (because it means just a single
alternation each time) and have general routines available to all
applications. My definition of programming efficiency excludes senseless
re-implementations of coding.

> It's not that you *can't* do all this yourself, but that you're possibly
> dealing with life at a layer or two lower than you might. Simply by using an
> existing library (say jpgraph, but it's chosen at random) you get a load of
> functionality (that gets improved over time) without having to implement any
> of it yourself. You're not simply producing a graph, you're producing code
> that draws a graph and then drawing a graph. Why write the code?

In this instance I would use a GMagick Draw function from with a
routine. The PHP coding would be minimal and straight-forward.


Paul.

_______________________________________________
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos
 
Old 09-15-2011, 02:30 PM
 
Default Upgrade from 5.6 => 5.7

In article <b0189c04b5d9a25bd50d4ceacf479b79.squirrel@mail. 5-cent.us>,
<m.roth@5-cent.us> wrote:
> John Hodrien wrote:
> > On Thu, 15 Sep 2011, Always Learning wrote:
> >> On Thu, 2011-09-15 at 05:16 -0700, Craig White wrote:
> >>
> >>> Gmagic/Imagick are somewhat incapable of doing graphing at all.
> >>
> >> Have you ever really looked ? What about GmagickDraw:oint and similar
> >> items ?
> >
> > I think the risk of the KISS approach is that you tend to reimplement
> > everything, because everything everyone else has done is overcomplicated.
>
> The "danger" of KISS approach? So, you endorse complex and complicated
> schemes? And here I thought that the True Believers in OO asserted that
> OOP was cleaner, simpler, and easier.

As Einstein said once: "Make everything as simple as possible, but not simpler."

More to the point would be: "Judging something *solely* on its simplicity
is an overly simplistic approach." -- Kiel Hodges. This appears to me
to be the trap that Paul Always Learning has fallen into.

Cheers
Tony
--
Tony Mountifield
Work: tony@softins.co.uk - http://www.softins.co.uk
Play: tony@mountifield.org - http://tony.mountifield.org
_______________________________________________
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos
 
Old 09-15-2011, 02:42 PM
Always Learning
 
Default Upgrade from 5.6 => 5.7

On Thu, 2011-09-15 at 14:30 +0000, Tony Mountifield wrote:


> More to the point would be: "Judging something *solely* on its
> simplicity is an overly simplistic approach." -- Kiel Hodges. This
> appears to me to be the trap that Paul Always Learning has fallen
> into.

Judge my systems on their:-

1. functionality (i.e. doing what is required)
2. speed
3. ease of use
4. ease of maintenance


--
With best regards,

Paul.
England,
EU.


_______________________________________________
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos
 
Old 09-15-2011, 03:06 PM
 
Default Upgrade from 5.6 => 5.7

In article <1316097747.32765.118.camel@m6.u226.com>,
Always Learning <centos@u61.u22.net> wrote:
>
> On Thu, 2011-09-15 at 14:30 +0000, Tony Mountifield wrote:
>
> > More to the point would be: "Judging something *solely* on its
> > simplicity is an overly simplistic approach." -- Kiel Hodges. This
> > appears to me to be the trap that Paul Always Learning has fallen
> > into.
>
> Judge my systems on their:-
>
> 1. functionality (i.e. doing what is required)
> 2. speed
> 3. ease of use
> 4. ease of maintenance

I can't do that, since I know nothing about them. All I can judge are
the comments you make here, such as your apparently simplistic view of
SQL and relational databases. For example, joins and views are
efficient and powerful if used correctly with a properly-designed
database, and relieve the application code of a lot of complexity,
reinvented wheels and scope for errors. Describing such constructs as
merely a complex overhead betrays a lack of understanding and a
reluctance to continue "always learning".

Cheers
Tony
--
Tony Mountifield
Work: tony@softins.co.uk - http://www.softins.co.uk
Play: tony@mountifield.org - http://tony.mountifield.org
_______________________________________________
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos
 
Old 09-15-2011, 03:09 PM
 
Default Upgrade from 5.6 => 5.7

Tony Mountifield wrote:
> In article <b0189c04b5d9a25bd50d4ceacf479b79.squirrel@mail. 5-cent.us>,
> <m.roth@5-cent.us> wrote:
>> John Hodrien wrote:
>> > On Thu, 15 Sep 2011, Always Learning wrote:
>> >> On Thu, 2011-09-15 at 05:16 -0700, Craig White wrote:
>> >>
>> >>> Gmagic/Imagick are somewhat incapable of doing graphing at all.
>> >>
>> >> Have you ever really looked ? What about GmagickDraw:oint and
>> >> similar items ?
>> >
>> > I think the risk of the KISS approach is that you tend to reimplement
>> > everything, because everything everyone else has done is
>> > overcomplicated.
>>
>> The "danger" of KISS approach? So, you endorse complex and complicated
>> schemes? And here I thought that the True Believers in OO asserted that
>> OOP was cleaner, simpler, and easier.
>
> As Einstein said once: "Make everything as simple as possible, but not
> simpler."
>
> More to the point would be: "Judging something *solely* on its simplicity
> is an overly simplistic approach." -- Kiel Hodges. This appears to me
> to be the trap that Paul Always Learning has fallen into.

I think you don't know enough of Paul's (or my) style to suggest that he's
fallen into any trap.

And my style, for stuff that's intended to be permanent, is aimed at
elegance, not cleverness. Cleverness is defined as that 02:00 or Fri,
16:45 phone call, followed by hours of "what the hell did I do last
year?". Elegance, and KISS, is fixing the problem and going back to sleep
or leaving on time.

mark

_______________________________________________
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos
 
Old 09-15-2011, 04:56 PM
Emmanuel Noobadmin
 
Default Upgrade from 5.6 => 5.7

On 9/15/11, Always Learning <centos@u61.u22.net> wrote:
> I have written 20+ complete systems using these and found them to be
> fast and very effective. Everyone who has seen my HTML, CSS, PHP, MySQL
> systems has been favourably impressed (me too!). MySQL is a fast
> database system. Never ever used a SQL join or view, just well designed
> databases with carefully planned tables - that is the art of good
> programming.

So how do you retrieve data that are kept in different tables? Or do
you simply replicate the same data in every single table that needs
it?

> Ajax/Jquery is someone else's parametrised programming language. It adds
> complexity and overhead to what is fundamentally a very basic task. Ajax
> etc. seem to appeal to people who are not good (or natural) programmers.
> Ajax etc. is like programming with boxing gloves on and taking several
> weeks to do it. If they want to use it, let them.

While I'd agree with you somewhat on jQuery and frameworks, AJAX isn't
the same thing. It's just a style of user interface that does make the
application more user-friendly. After all, in the hypothetical
accounting program, wouldn't typing a few letters in the invoicing
page to start displaying a list of possible customers be more
efficient than having to go to a separate search page to list and
select a customer?

>> also, I'd suggest using postgresql for better data integrity, and
>> anything-but-php (Python?) for better webside security.
>
> I have been using MySQL on Linux for about 4 years and never had a
> problem. What security issues has PHP ?

In my largely unresearched opinion, the same security issues that any
server side language might have: careless or naive programmers.
_______________________________________________
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos
 

Thread Tools




All times are GMT. The time now is 09:48 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org