Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.java.programmer > #21601 > unrolled thread
| Started by | Ramon F Herrera <ramon@conexus.net> |
|---|---|
| First post | 2013-01-22 06:41 -0800 |
| Last post | 2013-01-27 23:33 -0800 |
| Articles | 20 on this page of 106 — 15 participants |
Back to article view | Back to comp.lang.java.programmer
The Revenge of the Geeks Ramon F Herrera <ramon@conexus.net> - 2013-01-22 06:41 -0800
Re: The Revenge of the Geeks Melzzzzz <mel@zzzzz.com> - 2013-01-22 14:55 +0000
Re: The Revenge of the Geeks Arne Vajhøj <arne@vajhoej.dk> - 2013-01-22 22:29 -0500
Re: The Revenge of the Geeks Ramon F Herrera <ramon@conexus.net> - 2013-01-22 06:58 -0800
Re: The Revenge of the Geeks joel garry <joel-garry@home.com> - 2013-01-22 08:54 -0800
Re: The Revenge of the Geeks cipher <cipher@nospamforme.org> - 2013-01-23 00:07 +0000
Re: The Revenge of the Geeks Lew <lewbloch@gmail.com> - 2013-01-22 17:02 -0800
Re: The Revenge of the Geeks Arne Vajhøj <arne@vajhoej.dk> - 2013-01-22 22:23 -0500
Re: The Revenge of the Geeks BGB <cr88192@hotmail.com> - 2013-01-22 21:30 -0600
Re: The Revenge of the Geeks Arne Vajhøj <arne@vajhoej.dk> - 2013-01-22 22:26 -0500
Re: The Revenge of the Geeks cipher <cipher@nospamforme.org> - 2013-01-24 00:51 +0000
Re: The Revenge of the Geeks Arne Vajhøj <arne@vajhoej.dk> - 2013-01-23 20:01 -0500
Re: The Revenge of the Geeks cipher <cipher@nospamforme.org> - 2013-01-24 01:10 +0000
Re: The Revenge of the Geeks Arne Vajhøj <arne@vajhoej.dk> - 2013-01-23 20:20 -0500
Re: The Revenge of the Geeks cipher <cipher@nospamforme.org> - 2013-01-24 12:15 +0000
Re: The Revenge of the Geeks "Ezekiel" <zeke@nosuchemail.com> - 2013-01-24 07:37 -0500
Re: The Revenge of the Geeks lipska the kat <"nospam at neversurrender dot co dot uk"> - 2013-01-24 12:55 +0000
Re: The Revenge of the Geeks cipher <cipher@nospamforme.org> - 2013-01-24 14:40 +0000
Re: The Revenge of the Geeks "Ezekiel" <zeke@nosuchemail.com> - 2013-01-24 10:01 -0500
Re: The Revenge of the Geeks Arne Vajhøj <arne@vajhoej.dk> - 2013-01-24 10:24 -0500
Re: The Revenge of the Geeks Arne Vajhøj <arne@vajhoej.dk> - 2013-01-24 10:35 -0500
Re: The Revenge of the Geeks Arne Vajhøj <arne@vajhoej.dk> - 2013-01-24 10:56 -0500
Re: The Revenge of the Geeks Stuart <DerTopper@web.de> - 2013-01-30 23:54 +0100
Re: The Revenge of the Geeks Arne Vajhøj <arne@vajhoej.dk> - 2013-01-22 22:32 -0500
Re: The Revenge of the Geeks Kevin McMurtrie <mcmurtrie@pixelmemory.us> - 2013-01-22 21:33 -0800
Re: The Revenge of the Geeks BGB <cr88192@hotmail.com> - 2013-01-23 00:21 -0600
Re: The Revenge of the Geeks Arved Sandstrom <asandstrom2@eastlink.ca> - 2013-01-23 05:25 -0400
Re: The Revenge of the Geeks BGB <cr88192@hotmail.com> - 2013-01-23 04:35 -0600
Re: The Revenge of the Geeks Arne Vajhøj <arne@vajhoej.dk> - 2013-01-23 20:17 -0500
Re: The Revenge of the Geeks BGB <cr88192@hotmail.com> - 2013-01-23 22:47 -0600
Re: The Revenge of the Geeks Arved Sandstrom <asandstrom2@eastlink.ca> - 2013-01-24 06:03 -0400
Re: The Revenge of the Geeks BGB <cr88192@hotmail.com> - 2013-01-24 04:44 -0600
Re: The Revenge of the Geeks Arne Vajhøj <arne@vajhoej.dk> - 2013-01-24 11:10 -0500
Re: The Revenge of the Geeks lipska the kat <"nospam at neversurrender dot co dot uk"> - 2013-01-24 10:49 +0000
Re: The Revenge of the Geeks Arne Vajhøj <arne@vajhoej.dk> - 2013-01-24 11:06 -0500
Re: The Revenge of the Geeks BGB <cr88192@hotmail.com> - 2013-01-24 16:10 -0600
Re: The Revenge of the Geeks Arne Vajhøj <arne@vajhoej.dk> - 2013-01-24 17:30 -0500
Re: The Revenge of the Geeks BGB <cr88192@hotmail.com> - 2013-01-24 17:44 -0600
Re: The Revenge of the Geeks Arne Vajhøj <arne@vajhoej.dk> - 2013-01-24 17:49 -0500
Re: The Revenge of the Geeks Arne Vajhøj <arne@vajhoej.dk> - 2013-01-24 17:58 -0500
Re: The Revenge of the Geeks BGB <cr88192@hotmail.com> - 2013-01-24 21:10 -0600
Re: The Revenge of the Geeks Arne Vajhøj <arne@vajhoej.dk> - 2013-01-24 22:15 -0500
Re: The Revenge of the Geeks BGB <cr88192@hotmail.com> - 2013-01-24 22:31 -0600
Re: The Revenge of the Geeks Lew <lewbloch@gmail.com> - 2013-01-24 23:57 -0800
Re: The Revenge of the Geeks Arne Vajhøj <arne@vajhoej.dk> - 2013-01-25 22:05 -0500
Re: The Revenge of the Geeks BGB <cr88192@hotmail.com> - 2013-01-25 23:31 -0600
Re: The Revenge of the Geeks Arved Sandstrom <asandstrom2@eastlink.ca> - 2013-01-26 07:25 -0400
Re: The Revenge of the Geeks BGB <cr88192@hotmail.com> - 2013-01-26 12:40 -0600
Re: The Revenge of the Geeks Arved Sandstrom <asandstrom2@eastlink.ca> - 2013-01-26 21:34 -0400
Re: The Revenge of the Geeks Arne Vajhøj <arne@vajhoej.dk> - 2013-01-26 22:06 -0500
Re: The Revenge of the Geeks Arne Vajhøj <arne@vajhoej.dk> - 2013-01-26 09:12 -0500
Re: The Revenge of the Geeks BGB <cr88192@hotmail.com> - 2013-01-26 14:47 -0600
Re: The Revenge of the Geeks Arne Vajhøj <arne@vajhoej.dk> - 2013-01-26 16:23 -0500
Re: The Revenge of the Geeks BGB <cr88192@hotmail.com> - 2013-01-26 15:24 -0600
Re: The Revenge of the Geeks Arved Sandstrom <asandstrom2@eastlink.ca> - 2013-01-26 21:47 -0400
Re: The Revenge of the Geeks Arne Vajhøj <arne@vajhoej.dk> - 2013-01-26 22:11 -0500
Re: The Revenge of the Geeks BGB <cr88192@hotmail.com> - 2013-01-26 22:54 -0600
Re: The Revenge of the Geeks Arved Sandstrom <asandstrom2@eastlink.ca> - 2013-01-27 07:46 -0400
Re: The Revenge of the Geeks BGB <cr88192@hotmail.com> - 2013-01-27 12:47 -0600
Re: The Revenge of the Geeks Arne Vajhøj <arne@vajhoej.dk> - 2013-01-27 19:40 -0500
Re: The Revenge of the Geeks BGB <cr88192@hotmail.com> - 2013-01-27 21:16 -0600
Re: The Revenge of the Geeks Arne Vajhøj <arne@vajhoej.dk> - 2013-01-29 22:05 -0500
Re: The Revenge of the Geeks BGB <cr88192@hotmail.com> - 2013-01-30 03:22 -0600
Re: The Revenge of the Geeks Arne Vajhøj <arne@vajhoej.dk> - 2013-01-30 20:12 -0500
Re: The Revenge of the Geeks BGB <cr88192@hotmail.com> - 2013-01-31 02:22 -0600
Re: The Revenge of the Geeks Arne Vajhøj <arne@vajhoej.dk> - 2013-02-01 20:12 -0500
Re: The Revenge of the Geeks Gene Wirchenko <genew@telus.net> - 2013-02-04 14:09 -0800
Re: The Revenge of the Geeks Arne Vajhøj <arne@vajhoej.dk> - 2013-02-04 18:28 -0500
Re: The Revenge of the Geeks BGB <cr88192@hotmail.com> - 2013-02-05 01:57 -0600
Re: The Revenge of the Geeks Gene Wirchenko <genew@telus.net> - 2013-02-05 09:55 -0800
Re: The Revenge of the Geeks Arne Vajhøj <arne@vajhoej.dk> - 2013-01-27 19:37 -0500
Re: The Revenge of the Geeks lipska the kat <"nospam at neversurrender dot co dot uk"> - 2013-01-27 10:38 +0000
Re: The Revenge of the Geeks BGB <cr88192@hotmail.com> - 2013-01-27 13:09 -0600
Re: The Revenge of the Geeks Arne Vajhøj <arne@vajhoej.dk> - 2013-01-27 19:47 -0500
Re: The Revenge of the Geeks Arne Vajhøj <arne@vajhoej.dk> - 2013-01-27 19:45 -0500
Re: The Revenge of the Geeks Arved Sandstrom <asandstrom2@eastlink.ca> - 2013-01-26 07:26 -0400
Re: The Revenge of the Geeks BGB <cr88192@hotmail.com> - 2013-01-26 13:22 -0600
Re: The Revenge of the Geeks Lew <lewbloch@gmail.com> - 2013-01-26 12:57 -0800
Re: The Revenge of the Geeks BGB <cr88192@hotmail.com> - 2013-01-26 16:15 -0600
Re: The Revenge of the Geeks Arne Vajhøj <arne@vajhoej.dk> - 2013-01-26 22:04 -0500
Re: The Revenge of the Geeks BGB <cr88192@hotmail.com> - 2013-01-27 00:38 -0600
Re: The Revenge of the Geeks Arne Vajhøj <arne@vajhoej.dk> - 2013-01-27 19:35 -0500
Re: The Revenge of the Geeks BGB <cr88192@hotmail.com> - 2013-01-27 21:04 -0600
Re: The Revenge of the Geeks Arne Vajhøj <arne@vajhoej.dk> - 2013-01-26 16:34 -0500
Re: The Revenge of the Geeks BGB <cr88192@hotmail.com> - 2013-01-26 17:04 -0600
Re: The Revenge of the Geeks Arne Vajhøj <arne@vajhoej.dk> - 2013-01-26 22:14 -0500
Re: The Revenge of the Geeks BGB <cr88192@hotmail.com> - 2013-01-27 01:38 -0600
Re: The Revenge of the Geeks Martin Gregorie <martin@address-in-sig.invalid> - 2013-01-27 13:13 +0000
Re: The Revenge of the Geeks BGB <cr88192@hotmail.com> - 2013-01-27 13:59 -0600
Re: The Revenge of the Geeks Arne Vajhøj <arne@vajhoej.dk> - 2013-01-24 22:17 -0500
Re: The Revenge of the Geeks BGB <cr88192@hotmail.com> - 2013-01-24 23:06 -0600
Re: The Revenge of the Geeks Arne Vajhøj <arne@vajhoej.dk> - 2013-01-25 22:10 -0500
Re: The Revenge of the Geeks BGB <cr88192@hotmail.com> - 2013-01-26 00:31 -0600
Re: The Revenge of the Geeks Lew <lewbloch@gmail.com> - 2013-01-24 19:42 -0800
Re: The Revenge of the Geeks BGB <cr88192@hotmail.com> - 2013-01-24 23:22 -0600
Re: The Revenge of the Geeks Lew <lewbloch@gmail.com> - 2013-01-25 00:03 -0800
Re: The Revenge of the Geeks BGB <cr88192@hotmail.com> - 2013-01-25 02:41 -0600
Re: The Revenge of the Geeks Arved Sandstrom <asandstrom2@eastlink.ca> - 2013-01-24 19:31 -0400
Re: The Revenge of the Geeks Lew <lewbloch@gmail.com> - 2013-01-24 11:30 -0800
Re: The Revenge of the Geeks Arne Vajhøj <arne@vajhoej.dk> - 2013-01-23 20:13 -0500
Re: The Revenge of the Geeks Arved Sandstrom <asandstrom2@eastlink.ca> - 2013-01-24 15:31 -0400
Re: The Revenge of the Geeks Arne Vajhøj <arne@vajhoej.dk> - 2013-01-24 14:37 -0500
Re: The Revenge of the Geeks Arne Vajhøj <arne@vajhoej.dk> - 2013-01-23 20:09 -0500
Re: The Revenge of the Geeks Roedy Green <see_website@mindprod.com.invalid> - 2013-01-24 04:30 -0800
Re: The Revenge of the Geeks BGB <cr88192@hotmail.com> - 2013-01-25 02:45 -0600
Re: The Revenge of the Geeks Roedy Green <see_website@mindprod.com.invalid> - 2013-01-27 23:33 -0800
Page 4 of 6 — ← Prev page 1 2 3 [4] 5 6 Next page →
| From | BGB <cr88192@hotmail.com> |
|---|---|
| Date | 2013-01-27 21:16 -0600 |
| Message-ID | <ke4qlt$fke$1@news.albasani.net> |
| In reply to | #21809 |
On 1/27/2013 6:40 PM, Arne Vajhøj wrote: > On 1/27/2013 1:47 PM, BGB wrote: >> On 1/27/2013 5:46 AM, Arved Sandstrom wrote: >>> Usually in the enterprise world you have little or no leeway as to how >>> systems talk to each other. You may have a few options to choose from, >>> but rolling your own is looked upon askance. >>> >> >> well, this is where the whole "mandatory interop or orders from above" >> comes in. in such a case, people say what to do, and the programmer is >> expected to do so. >> >> but, I more meant for cases where a person has free say in the matter. >> >> and, also, a person still may choose an existing option, even if bad, >> because it is the least effort, or because it is still locally the best >> solution. >> >> like, rolling ones' own is not required, nor necessarily always the best >> option, but can't necessarily be summarily excluded simply for sake of >> "standards", as doing so may ultimately just make things worse overall. > > It almost can. > > If you go non standard and problems arise, then you are in > deep shit. > depends on costs... if "liability" is involved, or the functioning of the software is "mission critical" or something, then there is more reason for concern. for many types of apps though, hardly anyone gives a crap how any of it works internally anyways, and people can pretty much do whatever. (like, if it crashes or breaks violently, oh well, the user will start it up again, and at worst probably the user will think less of the product if it is too much of a buggy piece of crap, ...). granted, this is generally a reason to test things, like to verify that they basically work, and try to debug cases where things are prone to crash or otherwise go terribly wrong, ...
[toc] | [prev] | [next] | [standalone]
| From | Arne Vajhøj <arne@vajhoej.dk> |
|---|---|
| Date | 2013-01-29 22:05 -0500 |
| Message-ID | <51088de0$0$292$14726298@news.sunsite.dk> |
| In reply to | #21814 |
On 1/27/2013 10:16 PM, BGB wrote: > On 1/27/2013 6:40 PM, Arne Vajhøj wrote: >> On 1/27/2013 1:47 PM, BGB wrote: >>> On 1/27/2013 5:46 AM, Arved Sandstrom wrote: >>>> Usually in the enterprise world you have little or no leeway as to how >>>> systems talk to each other. You may have a few options to choose from, >>>> but rolling your own is looked upon askance. >>>> >>> >>> well, this is where the whole "mandatory interop or orders from above" >>> comes in. in such a case, people say what to do, and the programmer is >>> expected to do so. >>> >>> but, I more meant for cases where a person has free say in the matter. >>> >>> and, also, a person still may choose an existing option, even if bad, >>> because it is the least effort, or because it is still locally the best >>> solution. >>> >>> like, rolling ones' own is not required, nor necessarily always the best >>> option, but can't necessarily be summarily excluded simply for sake of >>> "standards", as doing so may ultimately just make things worse overall. >> >> It almost can. >> >> If you go non standard and problems arise, then you are in >> deep shit. >> > > depends on costs... > > if "liability" is involved, or the functioning of the software is > "mission critical" or something, then there is more reason for concern. > > > for many types of apps though, hardly anyone gives a crap how any of it > works internally anyways, and people can pretty much do whatever. > > (like, if it crashes or breaks violently, oh well, the user will start > it up again, and at worst probably the user will think less of the > product if it is too much of a buggy piece of crap, ...). Not everything is important. But best practices should be based on an assumption about it being important. Arne
[toc] | [prev] | [next] | [standalone]
| From | BGB <cr88192@hotmail.com> |
|---|---|
| Date | 2013-01-30 03:22 -0600 |
| Message-ID | <keaot9$9rv$1@news.albasani.net> |
| In reply to | #21851 |
On 1/29/2013 9:05 PM, Arne Vajhøj wrote: > On 1/27/2013 10:16 PM, BGB wrote: >> On 1/27/2013 6:40 PM, Arne Vajhøj wrote: >>> On 1/27/2013 1:47 PM, BGB wrote: >>>> On 1/27/2013 5:46 AM, Arved Sandstrom wrote: >>>>> Usually in the enterprise world you have little or no leeway as to how >>>>> systems talk to each other. You may have a few options to choose from, >>>>> but rolling your own is looked upon askance. >>>>> >>>> >>>> well, this is where the whole "mandatory interop or orders from above" >>>> comes in. in such a case, people say what to do, and the programmer is >>>> expected to do so. >>>> >>>> but, I more meant for cases where a person has free say in the matter. >>>> >>>> and, also, a person still may choose an existing option, even if bad, >>>> because it is the least effort, or because it is still locally the best >>>> solution. >>>> >>>> like, rolling ones' own is not required, nor necessarily always the >>>> best >>>> option, but can't necessarily be summarily excluded simply for sake of >>>> "standards", as doing so may ultimately just make things worse overall. >>> >>> It almost can. >>> >>> If you go non standard and problems arise, then you are in >>> deep shit. >>> >> >> depends on costs... >> >> if "liability" is involved, or the functioning of the software is >> "mission critical" or something, then there is more reason for concern. >> >> >> for many types of apps though, hardly anyone gives a crap how any of it >> works internally anyways, and people can pretty much do whatever. >> >> (like, if it crashes or breaks violently, oh well, the user will start >> it up again, and at worst probably the user will think less of the >> product if it is too much of a buggy piece of crap, ...). > > Not everything is important. > > But best practices should be based on an assumption about it > being important. > could be, or it could be that the importance of the system is another factor to be weighed in considering design choices (along with other design-quality concerns, concerns over what other people will think, of possible consequences, ...). like, if the importance is high, then choosing the most well proven technologies is best, and if fairly low, then it may mostly boil down to "whatever works". sometimes a person may be working more towards the most "elegant" solution, regarding whether or not it actually works, as a secondary concern (say, their whole premise is basically to write it, so that they can write a research paper about it). ... so, a lot is about balancing relevant factors, because while being well proven and standard technology is one thing, other factors, like development time, and how well it holds up against the offerings by ones' competitors, or how much end-user appeal there is, as well as potentially the computational performance, ... may also be factors. granted, in general, I guess I tend to go under the premise of "there should not be should", though there are exceptions to this, usually in cases where there is a significant potential impact on product quality, safety, or if there are potential legal, ethical, or moral, consequences. so, yeah, while freedom of choice is important, it also seems to be the case that a person should try to do the right thing. which in the case of a product, would mostly boil down to potential impacts to the quality of life or quality of experience to the end-users of a product (like, it is better not to rip people off of put their personal health or safety at risk, ...). but, it all depends a lot on the product. (like, if the product is actually in a position to pose a risk, ...). like, it is hard to find universal rules that would apply equally well to every sort of software. it is even like answering the question of which is better between float and double. and, meanwhile, some people think double isn't precise enough, leading to 128-bit floats, and others think a 32-bit float isn't cheap enough, leading to 16-bit half-floats. and, while both 128-bit and 16-bit floats are useful, what sorts of things they are useful for are very different (like, for example, if a person needs more than about 3 decimal digits of precision, ...). or such...
[toc] | [prev] | [next] | [standalone]
| From | Arne Vajhøj <arne@vajhoej.dk> |
|---|---|
| Date | 2013-01-30 20:12 -0500 |
| Message-ID | <5109c4ef$0$281$14726298@news.sunsite.dk> |
| In reply to | #21861 |
On 1/30/2013 4:22 AM, BGB wrote: > On 1/29/2013 9:05 PM, Arne Vajhøj wrote: >> On 1/27/2013 10:16 PM, BGB wrote: >>> On 1/27/2013 6:40 PM, Arne Vajhøj wrote: >>>> On 1/27/2013 1:47 PM, BGB wrote: >>>>> On 1/27/2013 5:46 AM, Arved Sandstrom wrote: >>>>>> Usually in the enterprise world you have little or no leeway as to >>>>>> how >>>>>> systems talk to each other. You may have a few options to choose >>>>>> from, >>>>>> but rolling your own is looked upon askance. >>>>>> >>>>> >>>>> well, this is where the whole "mandatory interop or orders from above" >>>>> comes in. in such a case, people say what to do, and the programmer is >>>>> expected to do so. >>>>> >>>>> but, I more meant for cases where a person has free say in the matter. >>>>> >>>>> and, also, a person still may choose an existing option, even if bad, >>>>> because it is the least effort, or because it is still locally the >>>>> best >>>>> solution. >>>>> >>>>> like, rolling ones' own is not required, nor necessarily always the >>>>> best >>>>> option, but can't necessarily be summarily excluded simply for sake of >>>>> "standards", as doing so may ultimately just make things worse >>>>> overall. >>>> >>>> It almost can. >>>> >>>> If you go non standard and problems arise, then you are in >>>> deep shit. >>>> >>> >>> depends on costs... >>> >>> if "liability" is involved, or the functioning of the software is >>> "mission critical" or something, then there is more reason for concern. >>> >>> >>> for many types of apps though, hardly anyone gives a crap how any of it >>> works internally anyways, and people can pretty much do whatever. >>> >>> (like, if it crashes or breaks violently, oh well, the user will start >>> it up again, and at worst probably the user will think less of the >>> product if it is too much of a buggy piece of crap, ...). >> >> Not everything is important. >> >> But best practices should be based on an assumption about it >> being important. >> > > could be, or it could be that the importance of the system is another > factor to be weighed in considering design choices (along with other > design-quality concerns, concerns over what other people will think, of > possible consequences, ...). > > like, if the importance is high, then choosing the most well proven > technologies is best, and if fairly low, then it may mostly boil down to > "whatever works". Not really. Unless there really is an advantage of going with the non-standard solution, then you would go for standard even for the less important stuff. > so, a lot is about balancing relevant factors, because while being well > proven and standard technology is one thing, other factors, like > development time, and how well it holds up against the offerings by > ones' competitors, or how much end-user appeal there is, as well as > potentially the computational performance, ... may also be factors. They can. But the home-made solutions often promise to be better but rarely delivers. Arne
[toc] | [prev] | [next] | [standalone]
| From | BGB <cr88192@hotmail.com> |
|---|---|
| Date | 2013-01-31 02:22 -0600 |
| Message-ID | <ked9nd$3sg$1@news.albasani.net> |
| In reply to | #21894 |
On 1/30/2013 7:12 PM, Arne Vajhøj wrote: > On 1/30/2013 4:22 AM, BGB wrote: >> On 1/29/2013 9:05 PM, Arne Vajhøj wrote: >>> On 1/27/2013 10:16 PM, BGB wrote: >>>> On 1/27/2013 6:40 PM, Arne Vajhøj wrote: >>>>> On 1/27/2013 1:47 PM, BGB wrote: >>>>>> On 1/27/2013 5:46 AM, Arved Sandstrom wrote: >>>>>>> Usually in the enterprise world you have little or no leeway as to >>>>>>> how >>>>>>> systems talk to each other. You may have a few options to choose >>>>>>> from, >>>>>>> but rolling your own is looked upon askance. >>>>>>> >>>>>> >>>>>> well, this is where the whole "mandatory interop or orders from >>>>>> above" >>>>>> comes in. in such a case, people say what to do, and the >>>>>> programmer is >>>>>> expected to do so. >>>>>> >>>>>> but, I more meant for cases where a person has free say in the >>>>>> matter. >>>>>> >>>>>> and, also, a person still may choose an existing option, even if bad, >>>>>> because it is the least effort, or because it is still locally the >>>>>> best >>>>>> solution. >>>>>> >>>>>> like, rolling ones' own is not required, nor necessarily always the >>>>>> best >>>>>> option, but can't necessarily be summarily excluded simply for >>>>>> sake of >>>>>> "standards", as doing so may ultimately just make things worse >>>>>> overall. >>>>> >>>>> It almost can. >>>>> >>>>> If you go non standard and problems arise, then you are in >>>>> deep shit. >>>>> >>>> >>>> depends on costs... >>>> >>>> if "liability" is involved, or the functioning of the software is >>>> "mission critical" or something, then there is more reason for concern. >>>> >>>> >>>> for many types of apps though, hardly anyone gives a crap how any of it >>>> works internally anyways, and people can pretty much do whatever. >>>> >>>> (like, if it crashes or breaks violently, oh well, the user will start >>>> it up again, and at worst probably the user will think less of the >>>> product if it is too much of a buggy piece of crap, ...). >>> >>> Not everything is important. >>> >>> But best practices should be based on an assumption about it >>> being important. >>> >> >> could be, or it could be that the importance of the system is another >> factor to be weighed in considering design choices (along with other >> design-quality concerns, concerns over what other people will think, of >> possible consequences, ...). >> >> like, if the importance is high, then choosing the most well proven >> technologies is best, and if fairly low, then it may mostly boil down to >> "whatever works". > > Not really. > > Unless there really is an advantage of going with the non-standard > solution, then you would go for standard even for the less important > stuff. > usually, there are advantages in edge-cases. in cases where a standard technology exists which does the job fairly well, then it usually makes most sense to use it. for example, PNG and JPEG are pretty good, so there are few reasons not to use them (for most things image-storage related). like, not being chained to standards, does not mean making a standard of non-standard either. where it makes more sense to ignore the standardized technologies is when they either aren't very good, or are notably bad (and actually using them would likely leave the product worse off). it is like, trying to take VRML seriously as a 3D model format. VRML is standardized, but the W3C at the time seemingly managed to get nearly everything wrong in the design. then later, they tried again with X3D, which sort of competes against COLLADA, which AFAICT is much more popular (despite X3D being shoved into a larger number of other standards, like HTML5 and MPEG-4...). likewise for the OSI protocols, ... people were largely just like "whatever" and continued using TCP/IP (IETF largely won this battle). nevermind if, officially (as per the standards), JPEG was replaced by JPEG-2000 around 13 years ago, and more recently there is JPEG-XR. meanwhile, the original JPEG remains the more well-supported format by most software (much easier to find apps which read/write JPEG images than JP2 or JXR images). ... sometimes, using a standard technology may actually make things worse off in other ways. for example, it is popular at present for people to make various file formats consisting of XML documents or similar packaged up into a ZIP-based container. while this is easier to approve as "open" or "standard", it comes with a drawback: some applications are prone to detect the ZIP-related magic values, and automatically change the file extension to ZIP, which can sometimes prove rather annoying (whereas, if a non-ZIP container format were used, these tools would more often leave the file alone). it also makes little sense if the intention is actually for the application to keep the data to itself, such as for a proprietary file-format, where it may actually be to ones advantage if unaware parties (such as competitors, ...) have little idea what the file contains. >> so, a lot is about balancing relevant factors, because while being well >> proven and standard technology is one thing, other factors, like >> development time, and how well it holds up against the offerings by >> ones' competitors, or how much end-user appeal there is, as well as >> potentially the computational performance, ... may also be factors. > > They can. > > But the home-made solutions often promise to be better but rarely > delivers. > I have generally been having generally good results with various custom-designed technologies. but, this again comes back to cost/benefit tradeoffs: if the results of the choice don't pay off well, it means they did not make a good choice, not that having had an option to make choice was to blame. like, having the freedom to make a choice does not mean freedom from any consequences of having made the choice. like, having freedom to make choices also means the freedom to shoot oneself in the foot. sometimes, a simple direct solution can also be better than a bigger "standard" solution, for example: passing simple lists or arrays for internal messages, vs using DOM or similar; using a HashMap or similar, vs using an RDBMS, to store key/value pairs or similar; passing plain data, rather than using RPC or similar; ... like, a possible premise: don't use a sledgehammer to do what can easily enough be done with a tack-hammer. like, even if the standard solution is to store data in a DBMS, the HashMap may be simpler, easier, and also potentially significantly faster, ... BTW: have been, mostly for the hell of it, in the process of porting my stuff to be able to work on Native Client. most of the work thus far is in trying to migrate the stupid 3D renderer from the full OpenGL to OpenGL ES. to make this work, I am as well having to make a "hand-made solution": namely, migrating much of the code from using normal OpenGL calls to using a set of wrapper functions (which will then fake things and pass the results off to GLES). (too much of the code still relies on the existence of the "fixed function pipeline", so for GLES it needs to all be faked...). I guess the more standard solution here would be to rewrite all the code directly (rather than forcing it onto wrappers), but this would be more work. but, then again, it is notably easier in this case to go with a non-standard technology (Native Client), even if largely tied to a single browser, than to go with a more standardized technology (IOW: trying to rewrite a 3D engine into HTML5+JS+WebGL to shove it into a browser). granted, for targeting a browser up-front (writing a new engine ground-up or similar), the HTML5+JS+WebGL route could probably make more sense (at least assuming "general" things, like that the browsers are smart enough to know how to cache compiled code and similar...).
[toc] | [prev] | [next] | [standalone]
| From | Arne Vajhøj <arne@vajhoej.dk> |
|---|---|
| Date | 2013-02-01 20:12 -0500 |
| Message-ID | <510c680f$0$286$14726298@news.sunsite.dk> |
| In reply to | #21913 |
On 1/31/2013 3:22 AM, BGB wrote: > On 1/30/2013 7:12 PM, Arne Vajhøj wrote: >> On 1/30/2013 4:22 AM, BGB wrote: >>> On 1/29/2013 9:05 PM, Arne Vajhøj wrote: >>>> On 1/27/2013 10:16 PM, BGB wrote: >>>>> On 1/27/2013 6:40 PM, Arne Vajhøj wrote: >>>>>> On 1/27/2013 1:47 PM, BGB wrote: >>>>>>> On 1/27/2013 5:46 AM, Arved Sandstrom wrote: >>>>>>>> Usually in the enterprise world you have little or no leeway as to >>>>>>>> how >>>>>>>> systems talk to each other. You may have a few options to choose >>>>>>>> from, >>>>>>>> but rolling your own is looked upon askance. >>>>>>>> >>>>>>> >>>>>>> well, this is where the whole "mandatory interop or orders from >>>>>>> above" >>>>>>> comes in. in such a case, people say what to do, and the >>>>>>> programmer is >>>>>>> expected to do so. >>>>>>> >>>>>>> but, I more meant for cases where a person has free say in the >>>>>>> matter. >>>>>>> >>>>>>> and, also, a person still may choose an existing option, even if >>>>>>> bad, >>>>>>> because it is the least effort, or because it is still locally the >>>>>>> best >>>>>>> solution. >>>>>>> >>>>>>> like, rolling ones' own is not required, nor necessarily always the >>>>>>> best >>>>>>> option, but can't necessarily be summarily excluded simply for >>>>>>> sake of >>>>>>> "standards", as doing so may ultimately just make things worse >>>>>>> overall. >>>>>> >>>>>> It almost can. >>>>>> >>>>>> If you go non standard and problems arise, then you are in >>>>>> deep shit. >>>>>> >>>>> >>>>> depends on costs... >>>>> >>>>> if "liability" is involved, or the functioning of the software is >>>>> "mission critical" or something, then there is more reason for >>>>> concern. >>>>> >>>>> >>>>> for many types of apps though, hardly anyone gives a crap how any >>>>> of it >>>>> works internally anyways, and people can pretty much do whatever. >>>>> >>>>> (like, if it crashes or breaks violently, oh well, the user will start >>>>> it up again, and at worst probably the user will think less of the >>>>> product if it is too much of a buggy piece of crap, ...). >>>> >>>> Not everything is important. >>>> >>>> But best practices should be based on an assumption about it >>>> being important. >>>> >>> >>> could be, or it could be that the importance of the system is another >>> factor to be weighed in considering design choices (along with other >>> design-quality concerns, concerns over what other people will think, of >>> possible consequences, ...). >>> >>> like, if the importance is high, then choosing the most well proven >>> technologies is best, and if fairly low, then it may mostly boil down to >>> "whatever works". >> >> Not really. >> >> Unless there really is an advantage of going with the non-standard >> solution, then you would go for standard even for the less important >> stuff. >> > > usually, there are advantages in edge-cases. It certainly happens. >>> so, a lot is about balancing relevant factors, because while being well >>> proven and standard technology is one thing, other factors, like >>> development time, and how well it holds up against the offerings by >>> ones' competitors, or how much end-user appeal there is, as well as >>> potentially the computational performance, ... may also be factors. >> >> They can. >> >> But the home-made solutions often promise to be better but rarely >> delivers. >> > > I have generally been having generally good results with various > custom-designed technologies. By the judgement of the author or by the judgement of neutral judges?? Arne
[toc] | [prev] | [next] | [standalone]
| From | Gene Wirchenko <genew@telus.net> |
|---|---|
| Date | 2013-02-04 14:09 -0800 |
| Message-ID | <asb0h81ruetmkpdhsmr2abs4p6ddsf618h@4ax.com> |
| In reply to | #21993 |
On Fri, 01 Feb 2013 20:12:39 -0500, Arne Vajhøj <arne@vajhoej.dk>
wrote:
[snip]
>By the judgement of the author or by the judgement of
>neutral judges??
Who cares about neutral judges? How about someone with some skin
in?
I maintain an in-house client billing app that has a form for
handling invoicing. There are 34 buttons for various general
functions that one might want to do and for each work order being
presented, there are two or three (depends on circumstances) more
buttons. This is the sort of design that could get submitted to the
Interface Hall of Shame.
However, and this is a big however, it makes invoicing fairly
easy. The owner of the company suggested the general approach. I
made it work. He uses it for invoicing, and when I was working Down
There, I was doing invoicing with it as well. It works and works
well.
But a neutral judge might choke on the buttons.
Sincerely,
Gene Wirchenko
[toc] | [prev] | [next] | [standalone]
| From | Arne Vajhøj <arne@vajhoej.dk> |
|---|---|
| Date | 2013-02-04 18:28 -0500 |
| Message-ID | <51104431$0$294$14726298@news.sunsite.dk> |
| In reply to | #22087 |
On 2/4/2013 5:09 PM, Gene Wirchenko wrote: > On Fri, 01 Feb 2013 20:12:39 -0500, Arne Vajhøj <arne@vajhoej.dk> > wrote: > > [snip] > >> By the judgement of the author or by the judgement of >> neutral judges?? > > Who cares about neutral judges? How about someone with some skin > in? > > I maintain an in-house client billing app that has a form for > handling invoicing. There are 34 buttons for various general > functions that one might want to do and for each work order being > presented, there are two or three (depends on circumstances) more > buttons. This is the sort of design that could get submitted to the > Interface Hall of Shame. > > However, and this is a big however, it makes invoicing fairly > easy. The owner of the company suggested the general approach. I > made it work. He uses it for invoicing, and when I was working Down > There, I was doing invoicing with it as well. It works and works > well. > > But a neutral judge might choke on the buttons. I doubt it. Good UX is different for different types of people. People that use an app a lot is known to prefer to have as much functionality as possible directly accessible without going through too much hassle. And anyway it is not really your idea, so you do not risk your judgement to be influenced by owners pride. The owner may be a poor judge as it is his baby. Arne
[toc] | [prev] | [next] | [standalone]
| From | BGB <cr88192@hotmail.com> |
|---|---|
| Date | 2013-02-05 01:57 -0600 |
| Message-ID | <keqe3l$2nk$1@news.albasani.net> |
| In reply to | #22095 |
On 2/4/2013 5:28 PM, Arne Vajhøj wrote: > On 2/4/2013 5:09 PM, Gene Wirchenko wrote: >> On Fri, 01 Feb 2013 20:12:39 -0500, Arne Vajhøj <arne@vajhoej.dk> >> wrote: >> >> [snip] >> >>> By the judgement of the author or by the judgement of >>> neutral judges?? >> >> Who cares about neutral judges? How about someone with some skin >> in? >> >> I maintain an in-house client billing app that has a form for >> handling invoicing. There are 34 buttons for various general >> functions that one might want to do and for each work order being >> presented, there are two or three (depends on circumstances) more >> buttons. This is the sort of design that could get submitted to the >> Interface Hall of Shame. >> >> However, and this is a big however, it makes invoicing fairly >> easy. The owner of the company suggested the general approach. I >> made it work. He uses it for invoicing, and when I was working Down >> There, I was doing invoicing with it as well. It works and works >> well. >> >> But a neutral judge might choke on the buttons. > > I doubt it. Good UX is different for different types > of people. People that use an app a lot is known to prefer > to have as much functionality as possible directly > accessible without going through too much hassle. > could be. I generally prefer keyboard shortcuts for a lot of things, and in general am not a fan of "wall of buttons" style GUIs, but don't really exactly think keyboard shortcuts are any one-true-user-input either. > And anyway it is not really your idea, so you do not risk > your judgement to be influenced by owners pride. The owner > may be a poor judge as it is his baby. > yeah, I am the user of a lot of my own stuff, so can't really be called a neutral-observer here here, and generally felt it pointless to try to argue over whether or not I can judge myself objectively... dealt with this problem enough even trying to resolve something as simple as personality type... (though on this one I did eventually settle on ISTP as probably most-likely-correct, despite so often coming off so much like an INTx...). but, yeah, I can claim to have good luck with my stuff, and whether or not other people think it is all crap, oh well, either way... as for determining whether or not a person is acting in accordance with their own best interests is, however, a similarly difficult problem, as is determining exactly what ones' best interests actually *are* (like, with the potential of inefficiency and opportunity cost and so on, leading to the issue that even a generally effective course of action may not necessarily be optimal). it seems that a person either ends up with potentially mutually contradictory conclusions (where the "self-interest value" becomes context-dependent), or has to deal with the ugly issue of (often arbitrary) "intrinsic properties", and the issue that there is no good way to validate whether "intrinsic worth" actually has worth, and if a person defines it in terms of self-benefit (or some other similar metric), they are right back where they started. (stupid philosophical logic circles...). easier just to be like "well, it works for me". it is generally much more effective IME to argue about things that can be tested and measured. elsewhere, I managed to get into an argument with people between storing images in PNG and JPEG, vs using DDS. I personally prefer PNG and JPEG... some people insisted though that DDS was essentially the "one true graphics format" and that PNG and JPEG and similar are essentially "legacy formats". I disagreed... there are plenty of reasons to prefer something like PNG or JPEG over something like DDS or BMP or similar. and, there are measurable reasons to prefer something like PNG or JPEG over DDS or BMP as well, ... well, and there is always WDP / JXR (HD Photo / JPEG-XR)... but, alas...
[toc] | [prev] | [next] | [standalone]
| From | Gene Wirchenko <genew@telus.net> |
|---|---|
| Date | 2013-02-05 09:55 -0800 |
| Message-ID | <vkh2h8pa155dhlcp37smagnpg445a0gu43@4ax.com> |
| In reply to | #22095 |
On Mon, 04 Feb 2013 18:28:47 -0500, Arne Vajhøj <arne@vajhoej.dk>
wrote:
>On 2/4/2013 5:09 PM, Gene Wirchenko wrote:
[snip]
>> But a neutral judge might choke on the buttons.
>
>I doubt it. Good UX is different for different types
Sorry. I have had too much exposure to people dissing things
that are not the way that they would do it.
>of people. People that use an app a lot is known to prefer
>to have as much functionality as possible directly
>accessible without going through too much hassle.
Last sentence: I had not thought of that exactly that way, but
yes, I think you nailed it there. Thank you for the insight.
>And anyway it is not really your idea, so you do not risk
>your judgement to be influenced by owners pride. The owner
>may be a poor judge as it is his baby.
If I go along with a bad idea in my area, I am culpable. I do
not have a problem with the design though. I thought at first that it
looked a bit odd, but my first priority is does it work? It works
well. And remember that I know that since I have used it to do real
work.
Sincerely,
Gene Wirchenko
[toc] | [prev] | [next] | [standalone]
| From | Arne Vajhøj <arne@vajhoej.dk> |
|---|---|
| Date | 2013-01-27 19:37 -0500 |
| Message-ID | <5105c860$0$288$14726298@news.sunsite.dk> |
| In reply to | #21787 |
On 1/26/2013 11:54 PM, BGB wrote: > On 1/26/2013 9:11 PM, Arne Vajhøj wrote: >> On 1/26/2013 8:47 PM, Arved Sandstrom wrote: >>> On 01/26/2013 04:47 PM, BGB wrote: >>>> On 1/26/2013 8:12 AM, Arne Vajhøj wrote: >>>>> On 1/26/2013 12:31 AM, BGB wrote: >>> [ SNIP ] >>>> >>>>>> FWIW: I once messed briefly with XML-RPC, but never really did much >>>>>> with >>>>>> it since then, although long ago, parts of its design were scavenged >>>>>> and >>>>>> repurposed for other things (compiler ASTs). >>>>> >>>>> XML-RPC never really took off. Instead we got SOAP. >>>>> >>>> >>>> I don't really like SOAP... >>> [ SNIP ] >>> >>> I don't know anyone who does, I know I don't. Still, it's what we've >>> got. For well-designed operations and schemas it's not that verbose, not >>> appreciably worse than JSON. Having WSDLs and the ability to validate is >>> useful, although over the years I've come to believe that WSDL-first is >>> an abomination unless the project is extremely structured and >>> disciplined. >>> >>> SOAP is also - still - the only game in town for various security and >>> transactional tasks, even if aspects of WS-Security are atrocious. For >>> true web services I'd use REST almost always, because SOAP actually >>> isn't much to do with the Web at all. But if I need application >>> security, encryption of portions of a message, non-repudiation, >>> transactionality etc,and I'm really doing RPC, I'm using SOAP. >> >> Standards are rarely optimal. >> But a standard is a standard. >> >> SOAP got the tools support and all the standards that >> build on top of it. >> >> We can either accept it and live happy with it or invent >> a time machine and go back to around 1998 and tell a few >> people from IBM and MS how it should be done. > > or just blow it off and do whatever... > > like, standards are useful so long as they are useful, but otherwise, > unless there is some greater reason (mandatory inter-op or orders from > above), why bother? > > like, unless is better for the project overall (or otherwise benefits > the developers in some way), why not just go and do something different? Because in the big picture compatibility is important and the potential improvements are not. Arne
[toc] | [prev] | [next] | [standalone]
| From | lipska the kat <"nospam at neversurrender dot co dot uk"> |
|---|---|
| Date | 2013-01-27 10:38 +0000 |
| Message-ID | <2PWdnbA58Jg6npjMnZ2dnUVZ8mSdnZ2d@bt.com> |
| In reply to | #21779 |
On 27/01/13 03:11, Arne Vajhøj wrote: > On 1/26/2013 8:47 PM, Arved Sandstrom wrote: >> On 01/26/2013 04:47 PM, BGB wrote: >>> On 1/26/2013 8:12 AM, Arne Vajhøj wrote: >>>> On 1/26/2013 12:31 AM, BGB wrote: [snip] > > people are not too happy about HTTP and SMTP either. huh ... what's wrong with HTTP ??? Nobody could possibly have imagined that HTTP would become such an important protocol. If people are unhappy about HTTP it's because they are trying to force the protocol to do things it was never designed to do. The fact that it *is* so flexible and extensible is surely testament to one mans vision and humanities ingenuity in general. I know we don't see eye to eye about many things Arne but that has to be one of your more absurd statements. I wonder how many contributors to this list would be making a (good) living out of 'IT' if HTTP and the World Wide Web had never been invented. lipska -- Lipska the Kat©: Troll hunter, sandbox destroyer and farscape dreamer of Aeryn Sun
[toc] | [prev] | [next] | [standalone]
| From | BGB <cr88192@hotmail.com> |
|---|---|
| Date | 2013-01-27 13:09 -0600 |
| Message-ID | <ke3u3h$hlv$1@news.albasani.net> |
| In reply to | #21794 |
On 1/27/2013 4:38 AM, lipska the kat wrote: > On 27/01/13 03:11, Arne Vajhøj wrote: >> On 1/26/2013 8:47 PM, Arved Sandstrom wrote: >>> On 01/26/2013 04:47 PM, BGB wrote: >>>> On 1/26/2013 8:12 AM, Arne Vajhøj wrote: >>>>> On 1/26/2013 12:31 AM, BGB wrote: > > [snip] > >> >> people are not too happy about HTTP and SMTP either. > > huh ... what's wrong with HTTP ??? > > Nobody could possibly have imagined that HTTP would > become such an important protocol. > > If people are unhappy about HTTP it's because they are trying to force > the protocol to do things it was never designed to do. The fact that it > *is* so flexible and extensible is surely testament to one mans vision > and humanities ingenuity in general. > > I know we don't see eye to eye about many things Arne but that has to be > one of your more absurd statements. > > I wonder how many contributors to this list would be making a (good) > living out of 'IT' if HTTP and the World Wide Web had never been invented. > probably the main issue is that it involves opening a connection for a single request/response pair, and doesn't (generally) allow reusing the socket for multiple requests (as-in, not without ugly hacks). to some extent, this has lead to the development of technologies like HTTP 2.0 / SPDY, and WebSockets, partly to better address some of these use-cases. but, for many apps, there may not be much need for HTTP inter-op, so they may develop their own protocols.
[toc] | [prev] | [next] | [standalone]
| From | Arne Vajhøj <arne@vajhoej.dk> |
|---|---|
| Date | 2013-01-27 19:47 -0500 |
| Message-ID | <5105caa9$0$288$14726298@news.sunsite.dk> |
| In reply to | #21803 |
On 1/27/2013 2:09 PM, BGB wrote: > On 1/27/2013 4:38 AM, lipska the kat wrote: >> On 27/01/13 03:11, Arne Vajhøj wrote: >>> On 1/26/2013 8:47 PM, Arved Sandstrom wrote: >>>> On 01/26/2013 04:47 PM, BGB wrote: >>>>> On 1/26/2013 8:12 AM, Arne Vajhøj wrote: >>>>>> On 1/26/2013 12:31 AM, BGB wrote: >> >> [snip] >> >>> >>> people are not too happy about HTTP and SMTP either. >> >> huh ... what's wrong with HTTP ??? >> >> Nobody could possibly have imagined that HTTP would >> become such an important protocol. >> >> If people are unhappy about HTTP it's because they are trying to force >> the protocol to do things it was never designed to do. The fact that it >> *is* so flexible and extensible is surely testament to one mans vision >> and humanities ingenuity in general. >> >> I know we don't see eye to eye about many things Arne but that has to be >> one of your more absurd statements. >> >> I wonder how many contributors to this list would be making a (good) >> living out of 'IT' if HTTP and the World Wide Web had never been >> invented. >> > > probably the main issue is that it involves opening a connection for a > single request/response pair, and doesn't (generally) allow reusing the > socket for multiple requests (as-in, not without ugly hacks). keep-alive has been used for many years. But it is certainly not without its problems. > to some extent, this has lead to the development of technologies like > HTTP 2.0 / SPDY, and WebSockets, partly to better address some of these > use-cases. Yep. Arne
[toc] | [prev] | [next] | [standalone]
| From | Arne Vajhøj <arne@vajhoej.dk> |
|---|---|
| Date | 2013-01-27 19:45 -0500 |
| Message-ID | <5105ca3e$0$288$14726298@news.sunsite.dk> |
| In reply to | #21794 |
On 1/27/2013 5:38 AM, lipska the kat wrote: > On 27/01/13 03:11, Arne Vajhøj wrote: >> On 1/26/2013 8:47 PM, Arved Sandstrom wrote: >>> On 01/26/2013 04:47 PM, BGB wrote: >>>> On 1/26/2013 8:12 AM, Arne Vajhøj wrote: >>>>> On 1/26/2013 12:31 AM, BGB wrote: > > [snip] > >> >> people are not too happy about HTTP and SMTP either. > > huh ... what's wrong with HTTP ??? Read about the reasons behind the HTTP 2.0 effort. > Nobody could possibly have imagined that HTTP would > become such an important protocol. True. But that just explains why we have the problems. It does not help solve the problems. > If people are unhappy about HTTP it's because they are trying to force > the protocol to do things it was never designed to do. The fact that it > *is* so flexible and extensible is surely testament to one mans vision > and humanities ingenuity in general. Almost everybody is forcing stuff on HTTP that it was not intended for these days. > I know we don't see eye to eye about many things Arne but that has to be > one of your more absurd statements. IETF, Google and Microsofts does not seem to think it is absurd since they are working to solve the problems. Arne
[toc] | [prev] | [next] | [standalone]
| From | Arved Sandstrom <asandstrom2@eastlink.ca> |
|---|---|
| Date | 2013-01-26 07:26 -0400 |
| Message-ID | <t3PMs.86406$sm1.29092@newsfe22.iad> |
| In reply to | #21692 |
On 01/25/2013 12:31 AM, BGB wrote: > On 1/24/2013 9:15 PM, Arne Vajhøj wrote: >> On 1/24/2013 10:10 PM, BGB wrote: >>> On 1/24/2013 4:58 PM, Arne Vajhøj wrote: >>>> On 1/24/2013 5:10 PM, BGB wrote: >>>>> On 1/24/2013 10:06 AM, Arne Vajhøj wrote: >>>>>> On 1/23/2013 11:47 PM, BGB wrote: >>>>>>> but, in any case, with the other languages there are a wide range of >>>>>>> libraries available, many under fairly open licenses (like MIT or >>>>>>> BSD), >>>>>>> and there is a lot more GPL stuff available, >>>>>> >>>>>> In the EE space you would need to look at CORBA or DCOM. >>>>>> >>>>>> You would prefer Java EE believe me. >>>>>> >>>>>> :-) >>>>>> >>>>> >>>>> errm, so you can't just copy all the files over to ones' servers? >>>>> and/or >>>>> recompile the code for ones' servers?... >>>> >>>> The coding model in Java EE is definitely more modern than that >>>> of CORBA and DCOM. >>>> >>> >>> I didn't mean like CORBA or DCOM, but probably directly copying over >>> program binaries (DLLs or SOs and precompiled binaries and similar), and >>> probably using traditional compilation and linking. >> >> You lost me. >> >> How to get the same type of services as Java EE provides is related >> to copying binaries how? >> > > I may be missing something here... [ SNIP ] Step back for a moment. We are talking servers and their clients. On the server side you start out with a vanilla install on a physical box or VM: might be Apache httpd or IIS, might be Tomcat or WebLogic, might be ActiveMQ or WebSphere MQ, might be Active Directory or OpenLDAP, might be H2 or DB2 or Oracle or SQL Server...you get the idea. The server install sets up directories, executables (services or tools), libraries (DLLs, *.so's, Java JARs etc), baseline config information, and so forth. At this stage of the game you may or may not have a useable, albeit uninteresting, server. Further configuration is often required to make it useable (e.g. the directory servers). After all this it's probably still uninteresting. You need to write server applications, and you need to develop clients (often, not always). For a web server or app server you write your ASP.NET MVC or Java EE or PHP apps. Those apps will use libraries that came with the baseline server, but you may use other libraries that are either shared on the server or bundled up/deployed with the specific server app. In some cases the actual server that you write your own server applications on is *itself* a server application sitting on a server. For example, ECM systems like FileNet P8 or Alfresco are actually humongo web apps (more or less) on app servers like Tomcat or WebSphere (plus using database servers and maybe directory servers) that you can the drop your own apps onto. IBM Cognos is itself a Java EE app. On the client side, if it's a web app you've got a browser; there's not anything left to do. But possibly your server application is providing SOAP or REST web services - in that case you will be writing client code. If CORBA, you're generating and writing client code. If WebSphere MQ you're often writing client code. These clients also need libraries, whether JARs or native shared/static libraries. Frequently there are client installers that supply all of this. You do not generally copy things in the manner you describe. Server installs can be pretty complicated - if you need a new server on a new box then you work through the approved install process...just like you'd do with an .EXE or .MSI installer for a standalone app on Windows. In fact, with few exceptions, *removing* a server and all its artifacts can be pretty complicated and tedious too. As to deployment of server and client apps, these often have a deployable form. In Java EE these are JARs or WARs or EARs. Other systems (ESBs, BPM systems, certain forms of IIS app deployment etc) often have a publishing/deployment procedure that involves ZIPs of directory/file structures. The IDE that you develop in, more often than not, already knows how to create the proper deployment packages. As for Java SE versus Java EE, the latter is the former plus reams of extra libraries. The latter also encompasses the contracts for anyone who is going to provide a Java EE-compliant application server. AHS
[toc] | [prev] | [next] | [standalone]
| From | BGB <cr88192@hotmail.com> |
|---|---|
| Date | 2013-01-26 13:22 -0600 |
| Message-ID | <ke1afi$lij$1@news.albasani.net> |
| In reply to | #21733 |
On 1/26/2013 5:26 AM, Arved Sandstrom wrote: > On 01/25/2013 12:31 AM, BGB wrote: >> On 1/24/2013 9:15 PM, Arne Vajhøj wrote: >>> On 1/24/2013 10:10 PM, BGB wrote: >>>> On 1/24/2013 4:58 PM, Arne Vajhøj wrote: >>>>> On 1/24/2013 5:10 PM, BGB wrote: >>>>>> On 1/24/2013 10:06 AM, Arne Vajhøj wrote: >>>>>>> On 1/23/2013 11:47 PM, BGB wrote: >>>>>>>> but, in any case, with the other languages there are a wide >>>>>>>> range of >>>>>>>> libraries available, many under fairly open licenses (like MIT or >>>>>>>> BSD), >>>>>>>> and there is a lot more GPL stuff available, >>>>>>> >>>>>>> In the EE space you would need to look at CORBA or DCOM. >>>>>>> >>>>>>> You would prefer Java EE believe me. >>>>>>> >>>>>>> :-) >>>>>>> >>>>>> >>>>>> errm, so you can't just copy all the files over to ones' servers? >>>>>> and/or >>>>>> recompile the code for ones' servers?... >>>>> >>>>> The coding model in Java EE is definitely more modern than that >>>>> of CORBA and DCOM. >>>>> >>>> >>>> I didn't mean like CORBA or DCOM, but probably directly copying over >>>> program binaries (DLLs or SOs and precompiled binaries and similar), >>>> and >>>> probably using traditional compilation and linking. >>> >>> You lost me. >>> >>> How to get the same type of services as Java EE provides is related >>> to copying binaries how? >>> >> >> I may be missing something here... > [ SNIP ] > > Step back for a moment. We are talking servers and their clients. On the > server side you start out with a vanilla install on a physical box or > VM: might be Apache httpd or IIS, might be Tomcat or WebLogic, might be > ActiveMQ or WebSphere MQ, might be Active Directory or OpenLDAP, might > be H2 or DB2 or Oracle or SQL Server...you get the idea. > > The server install sets up directories, executables (services or tools), > libraries (DLLs, *.so's, Java JARs etc), baseline config information, > and so forth. At this stage of the game you may or may not have a > useable, albeit uninteresting, server. Further configuration is often > required to make it useable (e.g. the directory servers). > > After all this it's probably still uninteresting. You need to write > server applications, and you need to develop clients (often, not > always). For a web server or app server you write your ASP.NET MVC or > Java EE or PHP apps. Those apps will use libraries that came with the > baseline server, but you may use other libraries that are either shared > on the server or bundled up/deployed with the specific server app. > > In some cases the actual server that you write your own server > applications on is *itself* a server application sitting on a server. > For example, ECM systems like FileNet P8 or Alfresco are actually > humongo web apps (more or less) on app servers like Tomcat or WebSphere > (plus using database servers and maybe directory servers) that you can > the drop your own apps onto. IBM Cognos is itself a Java EE app. > > On the client side, if it's a web app you've got a browser; there's not > anything left to do. But possibly your server application is providing > SOAP or REST web services - in that case you will be writing client > code. If CORBA, you're generating and writing client code. If WebSphere > MQ you're often writing client code. > > These clients also need libraries, whether JARs or native shared/static > libraries. Frequently there are client installers that supply all of this. > > You do not generally copy things in the manner you describe. Server > installs can be pretty complicated - if you need a new server on a new > box then you work through the approved install process...just like you'd > do with an .EXE or .MSI installer for a standalone app on Windows. > > In fact, with few exceptions, *removing* a server and all its artifacts > can be pretty complicated and tedious too. > > As to deployment of server and client apps, these often have a > deployable form. In Java EE these are JARs or WARs or EARs. Other > systems (ESBs, BPM systems, certain forms of IIS app deployment etc) > often have a publishing/deployment procedure that involves ZIPs of > directory/file structures. The IDE that you develop in, more often than > not, already knows how to create the proper deployment packages. > > As for Java SE versus Java EE, the latter is the former plus reams of > extra libraries. The latter also encompasses the contracts for anyone > who is going to provide a Java EE-compliant application server. > ... well, ok, I run a web-server mostly running Apache. apart from MediaWiki, most of the content thus far is static pages and files. so, not really some huge/complicated web-app thing, nor does it interact with any other servers (it contents are pretty much all self-contained, ...). I had generally imagined web-servers mostly like they were file-servers, but with the plus-side of having a defined browser-level interface, and the ability to use scripts or binaries to generate contents. for a client-side app (probably a traditional desktop-style application), it would use an HTTP server mostly like a file-server for retrieving updated resources and similar. a CGI script could mostly exist to provide a manifest and so the client app can know if/what files to download. dunno about an app working in a browser, I haven't personally really looked much into this. the one thing I had noted which I felt might make this worthwhile was "Google Native Client", but given it is Chrome-only at this point, this is a drawback (better if Firefox supported it, but the FF people apparently oppose it). Adobe Flash sometimes seemed like a possible option, but isn't particularly compelling, and the development environment apparently costs money. but, generally, I more prefer the desktop application experience...
[toc] | [prev] | [next] | [standalone]
| From | Lew <lewbloch@gmail.com> |
|---|---|
| Date | 2013-01-26 12:57 -0800 |
| Message-ID | <0e2d31c9-2da0-41f1-9055-d51781403d22@googlegroups.com> |
| In reply to | #21745 |
BGB wrote: > I had generally imagined web-servers mostly like they were file-servers, > but with the plus-side of having a defined browser-level interface, and > the ability to use scripts or binaries to generate contents. Terminology varies, but by widely-accepted convention a web server specifically handles browser-like interactions using (mostly) HTML over HTTP[S]. An application server, as others explained upthread, serves all kinds of services in service of applications designed to run in that environment. It might, and often does, incorporate a web server as part of the panoply of services provided. But the concept you must grasp is that application servers, such as those that implement Java EE, are kitchen-sink propositions, giving all kinds of help to applications from an "enterprise" (read "project", "organization", or professionally cognate term) perspective. You can play reductionist mind games all you want, I mean, really, isn't all "just" machine code in the end? Playing that type of game utterly misses the point and to reply in such terms is inappropriate. The point of any framework, or computer language, or toolkit, is to educe a closer mapping between the ontology of the enterprise (in its literal English meaning) and the ontology of the model you're building. To sit disingenuously in the wrong ontology serves neither your education nor contributes to the common weal. But you've been around this newsgroup a long, long time and by now you really should have found out some of this for yourself. Java EE is well documented and the tools are free and open source. So if you really had any genuine desire to understand the concepts and goals of the specifications, you'd've done so already. Java EE is like a high-level language, but for deployment and connection of services. It's one of those things that separates mere programmers from people who can solve problems with software systems. Its goals are deployability, scalability, ops-friendliness, orchestration-ability (sorry :-)), stability, and pragmatic leverage for useful software systems. It encompasses a broad range of tools, such as message queues, persistent storage, server clustering, resource management, orchestration, troubleshooting, and more. > for a client-side app (probably a traditional desktop-style > application), it would use an HTTP server mostly like a file-server for > retrieving updated resources and similar. a CGI script could mostly > exist to provide a manifest and so the client app can know if/what files > to download. > > dunno about an app working in a browser, I haven't personally really > looked much into this. the one thing I had noted which I felt might make > this worthwhile was "Google Native Client", but given it is Chrome-only > at this point, this is a drawback (better if Firefox supported it, but > the FF people apparently oppose it). > > Adobe Flash sometimes seemed like a possible option, but isn't > particularly compelling, and the development environment apparently > costs money. > > but, generally, I more prefer the desktop application experience... -- Lew
[toc] | [prev] | [next] | [standalone]
| From | BGB <cr88192@hotmail.com> |
|---|---|
| Date | 2013-01-26 16:15 -0600 |
| Message-ID | <ke1kjk$ad3$1@news.albasani.net> |
| In reply to | #21748 |
On 1/26/2013 2:57 PM, Lew wrote: > BGB wrote: >> I had generally imagined web-servers mostly like they were file-servers, >> but with the plus-side of having a defined browser-level interface, and >> the ability to use scripts or binaries to generate contents. > > Terminology varies, but by widely-accepted convention a web server specifically > handles browser-like interactions using (mostly) HTML over HTTP[S]. An application > server, as others explained upthread, serves all kinds of services in service of > applications designed to run in that environment. It might, and often does, incorporate > a web server as part of the panoply of services provided. But the concept you must > grasp is that application servers, such as those that implement Java EE, are kitchen-sink > propositions, giving all kinds of help to applications from an "enterprise" (read "project", > "organization", or professionally cognate term) perspective. > > You can play reductionist mind games all you want, I mean, really, isn't all "just" machine > code in the end? Playing that type of game utterly misses the point and to reply in such > terms is inappropriate. The point of any framework, or computer language, or toolkit, is > to educe a closer mapping between the ontology of the enterprise (in its literal English meaning) > and the ontology of the model you're building. To sit disingenuously in the wrong ontology > serves neither your education nor contributes to the common weal. > my view of things is typically built from seeing how the lower layers work, and how all the parts then fit together on top of this. this "reductionism" is mostly trying to figure out how the tower is built and how the parts generally fit together (and which parts comprise various mechanisms, concepts, ...). like, it doesn't make much sense to see the high-level apart from the structures which support its operation. like, what web-servers do makes little sense, apart from considering what HTTP itself does. not that there can't be abstractions, but normally at least these abstractions need some sort of basis or foundation for their behavior (even if incomplete or weak). > But you've been around this newsgroup a long, long time and by now you really should have > found out some of this for yourself. Java EE is well documented and the tools are free and open > source. So if you really had any genuine desire to understand the concepts and goals of the > specifications, you'd've done so already. > I never really went anywhere near Java EE though... I had always thought the relation was between Java SE and EE was more like that between, say, "Windows 7 Home" and "Windows 7 Ultimate", IOW: there are differences, but they largely do the same things in the same way. then just suddenly realizing that this is not the case, but that they are in-fact rather different things. > Java EE is like a high-level language, but for deployment and connection of services. It's one of > those things that separates mere programmers from people who can solve problems with software > systems. Its goals are deployability, scalability, ops-friendliness, orchestration-ability (sorry :-)), > stability, and pragmatic leverage for useful software systems. It encompasses a broad range of tools, > such as message queues, persistent storage, server clustering, resource management, orchestration, > troubleshooting, and more. > well, but it is also apparently intended for network/internet stuff. in contrast to say, writing standalone apps for a desktop PC or an Android phone or similar. there is not a single type of programmer, or software, and there are many types of software which may have little to do with either business or the internet. like, say, if a person is developing a game on their PC or cell-phone, is a lot of this stuff involved? probably not. if a person is running a big website, it probably matters, but not for a single-player game, nor necessarily for traditional multiplayer (which usually has a cap of around 8 or 16 players on a single server, and where servers typically only exist briefly, and disappear when the person hosting the server exits the game). there are requirements, but they are typically different requirements (for example, if using a network, bandwidth and latency may be much bigger concerns than scalability, since it all has to be real-time and typically all goes through a single-persons' home internet connection, ...). likewise, even for a small-scale website, it may not matter all that much, if all it ever does is mostly serve up static content and files, any is typically low-traffic (and, likewise, is served via a home internet connection), ... >> for a client-side app (probably a traditional desktop-style >> application), it would use an HTTP server mostly like a file-server for >> retrieving updated resources and similar. a CGI script could mostly >> exist to provide a manifest and so the client app can know if/what files >> to download. >> >> dunno about an app working in a browser, I haven't personally really >> looked much into this. the one thing I had noted which I felt might make >> this worthwhile was "Google Native Client", but given it is Chrome-only >> at this point, this is a drawback (better if Firefox supported it, but >> the FF people apparently oppose it). >> >> Adobe Flash sometimes seemed like a possible option, but isn't >> particularly compelling, and the development environment apparently >> costs money. >> >> but, generally, I more prefer the desktop application experience... >
[toc] | [prev] | [next] | [standalone]
| From | Arne Vajhøj <arne@vajhoej.dk> |
|---|---|
| Date | 2013-01-26 22:04 -0500 |
| Message-ID | <51049960$0$293$14726298@news.sunsite.dk> |
| In reply to | #21757 |
On 1/26/2013 5:15 PM, BGB wrote: > On 1/26/2013 2:57 PM, Lew wrote: >> But you've been around this newsgroup a long, long time and by now you >> really should have >> found out some of this for yourself. Java EE is well documented and >> the tools are free and open >> source. So if you really had any genuine desire to understand the >> concepts and goals of the >> specifications, you'd've done so already. >> > > I never really went anywhere near Java EE though... Most Java developers work full time or part time in an EE environment, but some does not. We may have a tendency to forget about that. Please forgive us for that. > I had always thought the relation was between Java SE and EE was more > like that between, say, "Windows 7 Home" and "Windows 7 Ultimate", IOW: > there are differences, but they largely do the same things in the same way. > > then just suddenly realizing that this is not the case, but that they > are in-fact rather different things. The terms SE and EE do give the wrong impression. For almost all other products SE and EE means same type of product with different feature set and different price point (SE support up to 4 CPU, do not support clustering and cost 10 K$ - EE support up to 16 CPU, do support clustering and cost 100 K$). For Java EE is a server centric framework on top of SE that is general purpose. >> Java EE is like a high-level language, but for deployment and >> connection of services. It's one of >> those things that separates mere programmers from people who can solve >> problems with software >> systems. Its goals are deployability, scalability, ops-friendliness, >> orchestration-ability (sorry :-)), >> stability, and pragmatic leverage for useful software systems. It >> encompasses a broad range of tools, >> such as message queues, persistent storage, server clustering, >> resource management, orchestration, >> troubleshooting, and more. > > well, but it is also apparently intended for network/internet stuff. Web apps can utilize much of this. It is standard with clustering for web apps and web apps require some support for HTTP, thread pool, transactions etc.. > in contrast to say, writing standalone apps for a desktop PC or an > Android phone or similar. They may need some of those features, but typical not many. > there is not a single type of programmer, or software, and there are > many types of software which may have little to do with either business > or the internet. Internet is quite common. But client side can use internet without EE. > like, say, if a person is developing a game on their PC or cell-phone, > is a lot of this stuff involved? probably not. Yep. > likewise, even for a small-scale website, it may not matter all that > much, if all it ever does is mostly serve up static content and files, > any is typically low-traffic (and, likewise, is served via a home > internet connection), ... Even for a small scale web site the convenience of Tomcat over a CGI-BIN could justify EE (or PHP or ASP.NET if Java is not a prerequisite). Arne
[toc] | [prev] | [next] | [standalone]
Page 4 of 6 — ← Prev page 1 2 3 [4] 5 6 Next page →
Back to top | Article view | comp.lang.java.programmer
csiph-web