Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.java.programmer > #39227 > unrolled thread

How bad i are my coding skills?

Back to article view | Back to comp.lang.java.programmer

Contents

  How bad i are my coding skills? chad altenburg <cdalten@gmail.com> - 2019-12-26 14:46 -0800
    Re: How bad i are my coding skills? Eric Sosman <esosman@comcast-dot-net.invalid> - 2019-12-27 09:28 -0500
      Re: How bad i are my coding skills? Eric Douglas <e.d.programmer@gmail.com> - 2019-12-27 08:13 -0800
        Re: How bad i are my coding skills? Arne Vajhøj <arne@vajhoej.dk> - 2019-12-27 13:11 -0500
        Re: How bad i are my coding skills? Eric Sosman <esosman@comcast-dot-net.invalid> - 2019-12-27 13:33 -0500
          Re: How bad i are my coding skills? Arne Vajhøj <arne@vajhoej.dk> - 2019-12-27 13:47 -0500
            Re: How bad i are my coding skills? Eric Douglas <e.d.programmer@gmail.com> - 2019-12-27 11:14 -0800
              Re: How bad i are my coding skills? Arne Vajhøj <arne@vajhoej.dk> - 2019-12-27 16:09 -0500
                Re: How bad i are my coding skills? Martin Gregorie <martin@mydomain.invalid> - 2019-12-27 23:10 +0000
                  Re: How bad i are my coding skills? chad altenburg <cdalten@gmail.com> - 2019-12-27 16:58 -0800
        Re: How bad i are my coding skills? Daniele Futtorovic <da.futt.news@laposte-dot-net.invalid> - 2019-12-30 01:27 +0100
        Re: How bad i are my coding skills? Arne Vajhøj <arne@vajhoej.dk> - 2019-12-29 19:34 -0500
          Re: How bad i are my coding skills? chad altenburg <cdalten@gmail.com> - 2019-12-30 05:13 -0800
            Re: How bad i are my coding skills? chad altenburg <cdalten@gmail.com> - 2019-12-30 05:46 -0800
              Re: How bad i are my coding skills? Martin Gregorie <martin@mydomain.invalid> - 2019-12-30 14:48 +0000
              Re: How bad i are my coding skills? Arne Vajhøj <arne@vajhoej.dk> - 2019-12-30 15:11 -0500
                Re: How bad i are my coding skills? Eric Sosman <esosman@comcast-dot-net.invalid> - 2019-12-30 15:55 -0500
                  Re: How bad i are my coding skills? Arne Vajhøj <arne@vajhoej.dk> - 2019-12-30 18:51 -0500
                    Re: How bad i are my coding skills? chad altenburg <cdalten@gmail.com> - 2019-12-31 05:10 -0800
              Re: How bad i are my coding skills? Daniele Futtorovic <da.futt.news@laposte-dot-net.invalid> - 2020-01-02 04:20 +0100
            Re: How bad i are my coding skills? Eric Sosman <esosman@comcast-dot-net.invalid> - 2019-12-30 08:51 -0500
              Re: How bad i are my coding skills? chad altenburg <cdalten@gmail.com> - 2019-12-30 10:25 -0800
    Re: How bad i are my coding skills? Daniele Futtorovic <da.futt.news@laposte-dot-net.invalid> - 2019-12-30 01:25 +0100
      Re: How bad i are my coding skills? chad altenburg <cdalten@gmail.com> - 2019-12-30 05:07 -0800
        Re: How bad i are my coding skills? Daniele Futtorovic <da.futt.news@laposte-dot-net.invalid> - 2020-01-02 04:27 +0100
          Re: How bad i are my coding skills? chad altenburg <cdalten@gmail.com> - 2020-01-02 05:46 -0800
            Re: How bad i are my coding skills? Eric Sosman <esosman@comcast-dot-net.invalid> - 2020-01-02 10:43 -0500
              Re: How bad i are my coding skills? chad altenburg <cdalten@gmail.com> - 2020-01-03 04:54 -0800
                Re: How bad i are my coding skills? chad altenburg <cdalten@gmail.com> - 2020-01-03 05:00 -0800
                  Re: How bad i are my coding skills? Eric Sosman <esosman@comcast-dot-net.invalid> - 2020-01-03 11:05 -0500
                    Re: How bad i are my coding skills? chad altenburg <cdalten@gmail.com> - 2020-01-03 13:54 -0800
                Re: How bad i are my coding skills? Daniele Futtorovic <da.futt.news@laposte-dot-net.invalid> - 2020-01-05 18:00 +0100

Page 1 of 2  [1] 2  Next page →

#39227 — How bad i are my coding skills?

I wrote my first Java based app for the Android smartphone. This was done by myself. Here are the stats for my first app...

1)Spending 10 hrs a week on it, it has taken me 20 months to get 95% if it complete.

2)During this time I rewrote parts of it twice. I also did a few optimizations during this process.

3)The Java code itself almost 6000 lines.

4)I found and corrected almost 120 bugs. These were mainly off by one and memory leaks.


And all of this was done while charging my phone at Starbucks and drinking Coffee between the hrs of 6am to 8am, M-F.

[toc] | [next] | [standalone]

#39228

On 12/26/2019 5:46 PM, chad altenburg wrote:
> I wrote my first Java based app for the Android smartphone. This was done by myself. Here are the stats for my first app...
> 
> 1)Spending 10 hrs a week on it, it has taken me 20 months to get 95% if it complete.

     The first 95% of the job takes 95% of the time.  The remaining 5% of
the job takes the other 95% of the time ...

> 2)During this time I rewrote parts of it twice. I also did a few optimizations during this process.

     Seriously: If you don't even have the thing working yet ("95% if it
complete"), you shouldn't be trying to optimize yet.

> 3)The Java code itself almost 6000 lines.

     In 200 hours?  Lines are surely not all of equal difficulty, but
this seems a rather, uh, "leisurely" pace.

> 4)I found and corrected almost 120 bugs. These were mainly off by one and memory leaks.

     "Memory leaks" in Java?  There's a related phenomenon often called
"packratting," but the classical memory leak is mostly obviated by the
garbage collector.  If whatever problem you're experiencing is common
enough to merit "mainly," I'm suspicious that you may not have diagnosed
it correctly.

> And all of this was done while charging my phone at Starbucks and drinking Coffee between the hrs of 6am to 8am, M-F.

     Aha!  That explains it: Starbucks coffee is not the proper fuel for
coding.  In fact, it's vile.

-- 
esosman@comcast-dot-net.invalid
Three hundred ninety days to go.

[toc] | [prev] | [next] | [standalone]

#39230

On Friday, December 27, 2019 at 9:28:44 AM UTC-5, Eric Sosman wrote:
> On 12/26/2019 5:46 PM, chad altenburg wrote:
> > I wrote my first Java based app for the Android smartphone. This was done by myself. Here are the stats for my first app...
> > 
> > 1)Spending 10 hrs a week on it, it has taken me 20 months to get 95% if it complete.
> 
>      The first 95% of the job takes 95% of the time.  The remaining 5% of
> the job takes the other 95% of the time ...
> 
> > 2)During this time I rewrote parts of it twice. I also did a few optimizations during this process.
> 
>      Seriously: If you don't even have the thing working yet ("95% if it
> complete"), you shouldn't be trying to optimize yet.
> 
> > 3)The Java code itself almost 6000 lines.
> 
>      In 200 hours?  Lines are surely not all of equal difficulty, but
> this seems a rather, uh, "leisurely" pace.
> 
200 hours?  He said 10 hours/week for 20 months, that's at least 800 hours.

> > 4)I found and corrected almost 120 bugs. These were mainly off by one and memory leaks.
> 
>      "Memory leaks" in Java?  There's a related phenomenon often called
> "packratting," but the classical memory leak is mostly obviated by the
> garbage collector.  If whatever problem you're experiencing is common
> enough to merit "mainly," I'm suspicious that you may not have diagnosed
> it correctly.
> 
I wrote a memory leak once.  For memory leaks to be a significant problem in Java coding I suspect the coder really doesn't know what they're doing? not sure what 'off by one' issues are (or what sort of app this is)

> > And all of this was done while charging my phone at Starbucks and drinking Coffee between the hrs of 6am to 8am, M-F.
> 
>      Aha!  That explains it: Starbucks coffee is not the proper fuel for
> coding.  In fact, it's vile.
> 
Starbucks coffee too expensive for me.  I buy the store brands and make 1 cup a day in the re-usable cup with my keurig.

[toc] | [prev] | [next] | [standalone]

#39231

On 12/27/2019 11:13 AM, Eric Douglas wrote:
> On Friday, December 27, 2019 at 9:28:44 AM UTC-5, Eric Sosman wrote:
>> On 12/26/2019 5:46 PM, chad altenburg wrote:
>>> 4)I found and corrected almost 120 bugs. These were mainly off by
>>> one and memory leaks.
>> 
>> "Memory leaks" in Java?  There's a related phenomenon often called 
>> "packratting," but the classical memory leak is mostly obviated by
>> the garbage collector.  If whatever problem you're experiencing is
>> common enough to merit "mainly," I'm suspicious that you may not
>> have diagnosed it correctly.
> 
> I wrote a memory leak once.  For memory leaks to be a significant
> problem in Java coding I suspect the coder really doesn't know what
> they're doing? not sure what 'off by one' issues are (or what sort of
> app this is)

I think it is just difference in terminology.

If one use terms:

memory leak = forgetting to explicit free memory before last
pointer to it is lost

packratting = forgetting to get rid of last reference to object
and thereby preventing it from being garbage collected

Then Java do not have memory leaks.

If you define both problems as being memory leak, then Java do
have memory leaks.

Arne

[toc] | [prev] | [next] | [standalone]

#39232

On 12/27/2019 11:13 AM, Eric Douglas wrote:
> On Friday, December 27, 2019 at 9:28:44 AM UTC-5, Eric Sosman wrote:
>> On 12/26/2019 5:46 PM, chad altenburg wrote:
>>> I wrote my first Java based app for the Android smartphone. This was done by myself. Here are the stats for my first app...
>>>
>>> 1)Spending 10 hrs a week on it, it has taken me 20 months to get 95% if it complete.
>>[...]
>>       In 200 hours?  Lines are surely not all of equal difficulty, but
>> this seems a rather, uh, "leisurely" pace.
>>
> 200 hours?  He said 10 hours/week for 20 months, that's at least 800 hours.

     Thanks for the correction!  I'll retract "leisurely" and substitute
"dead-slow, dawdling, and dilatory."  (What with all that Starbucks
coffee his months probably go by a lot faster than yours and mine ...)

-- 
esosman@comcast-dot-net.invalid
Three hundred ninety days to go.

[toc] | [prev] | [next] | [standalone]

#39233

On 12/27/2019 1:33 PM, Eric Sosman wrote:
> On 12/27/2019 11:13 AM, Eric Douglas wrote:
>> On Friday, December 27, 2019 at 9:28:44 AM UTC-5, Eric Sosman wrote:
>>> On 12/26/2019 5:46 PM, chad altenburg wrote:
>>>> I wrote my first Java based app for the Android smartphone. This was 
>>>> done by myself. Here are the stats for my first app...
>>>>
>>>> 1)Spending 10 hrs a week on it, it has taken me 20 months to get 95% 
>>>> if it complete.
>>> [...]
>>>       In 200 hours?  Lines are surely not all of equal difficulty, but
>>> this seems a rather, uh, "leisurely" pace.
>>>
>> 200 hours?  He said 10 hours/week for 20 months, that's at least 800 
>> hours.
> 
>      Thanks for the correction!  I'll retract "leisurely" and substitute
> "dead-slow, dawdling, and dilatory."

It was 6000 lines.

It may be pretty slow for "XXXX lines for learning" programming.

But for a real project it would be OK. 10-30 lines per day is
supposedly industry standard.

Arne

[toc] | [prev] | [next] | [standalone]

#39234

On Friday, December 27, 2019 at 1:47:40 PM UTC-5, Arne Vajhøj wrote:
> It was 6000 lines.
> 
> It may be pretty slow for "XXXX lines for learning" programming.
> 
> But for a real project it would be OK. 10-30 lines per day is
> supposedly industry standard.
> 
> Arne

To look at what I've accomplished I look at number of tasks, size of tasks, how long did they take.  I never counted lines of code much less tried to figure lines per hour.

[toc] | [prev] | [next] | [standalone]

#39236

On 12/27/2019 2:14 PM, Eric Douglas wrote:
> On Friday, December 27, 2019 at 1:47:40 PM UTC-5, Arne Vajhøj wrote:
>> It was 6000 lines.
>>
>> It may be pretty slow for "XXXX lines for learning" programming.
>>
>> But for a real project it would be OK. 10-30 lines per day is
>> supposedly industry standard.
> 
> To look at what I've accomplished I look at number of tasks, size of
> tasks, how long did they take.  I never counted lines of code much
> less tried to figure lines per hour.
For a given problem less code complexity (which is usually somewhat
related to less lines of code) is better.

But for large projects then averages rules.

Arne

[toc] | [prev] | [next] | [standalone]

#39237

On Fri, 27 Dec 2019 16:09:21 -0500, Arne Vajhøj wrote:

> On 12/27/2019 2:14 PM, Eric Douglas wrote:
>> On Friday, December 27, 2019 at 1:47:40 PM UTC-5, Arne Vajhøj wrote:
>>> It was 6000 lines.
>>>
>>> It may be pretty slow for "XXXX lines for learning" programming.
>>>
>>> But for a real project it would be OK. 10-30 lines per day is
>>> supposedly industry standard.
>> 
>> To look at what I've accomplished I look at number of tasks, size of
>> tasks, how long did they take.  I never counted lines of code much less
>> tried to figure lines per hour.
> For a given problem less code complexity (which is usually somewhat
> related to less lines of code) is better.
> 
> But for large projects then averages rules.
> 
But the number of lines of code written, compiled and tested and ready to 
be released for acceptance testing by the client can vary a lot between 
developers. One project I was on a long time back (a financial message 
switch written in PL/1 and running on a Stratus fault-tolerant system) 
have developer productivity metrics ranging from 25 lines/day to 125 
lines/day.


-- 
Martin    | martin at
Gregorie  | gregorie dot org

[toc] | [prev] | [next] | [standalone]

#39238

The Java API for Android has this feature where you can store value pairs in the memory. The memory leaks come from if I don't uninstall the old app, but instead, install the new app on top of the old app.

The Java API for Android Android also has this thing called "context". When misused, it's possible to have a reference to an object once the object has been garbage collected.

[toc] | [prev] | [next] | [standalone]

#39240

On 2019-12-27 17:13, Eric Douglas wrote:
> not sure what 'off by one' issues are

I read about that once in home ed' class. It's when you're still single
at thirty even though your mom's been telling you for ages that you need
to get married. Right? Right?

-- 
DF.

[toc] | [prev] | [next] | [standalone]

#39241

On 12/27/2019 11:13 AM, Eric Douglas wrote:
> not sure what 'off by one' issues are

Usually this means code like a[i+2] that should have been either
a[i+1] or a[i+3].

Wikipedia has some slightly different examples 
https://en.wikipedia.org/wiki/Off-by-one_error
but I associate it with the array index calculation being one off.

BTW, such an error happening is actually revealing a code smell. Data
structures and code logic should be written so that it is very difficult
to make such an error.

Arne

[toc] | [prev] | [next] | [standalone]

#39243

On Sunday, December 29, 2019 at 4:34:57 PM UTC-8, Arne Vajhøj wrote:
> On 12/27/2019 11:13 AM, Eric Douglas wrote:
> > not sure what 'off by one' issues are
> 
> Usually this means code like a[i+2] that should have been either
> a[i+1] or a[i+3].
> 
> Wikipedia has some slightly different examples 
> https://en.wikipedia.org/wiki/Off-by-one_error
> but I associate it with the array index calculation being one off.
> 
> BTW, such an error happening is actually revealing a code smell. Data
> structures and code logic should be written so that it is very difficult
> to make such an error.
> 

And I don't know of any sane and rational method to go about doing it. It goes like this. Internally, the data has the format like

[StartHour, StartMinute, StartAmOrPm, EndHour, EndMinute, EndAmOrPm]

Now what happens say I want to add a flag to switch this data because I want to take the day off. Yes, I can clear the data. But I would still need an additional piece of data added to this format so when if I traverse of this list, the app knows to do whatever when it sees the "day off" flag.

Likewise, what happens if I want to take a day off, and still get paid? Maybe I want to do this because I want to use some paid personal time (PTO) off before the end of the year. This is because my PTO might not carry over to the following year.

[toc] | [prev] | [next] | [standalone]

#39244

On Monday, December 30, 2019 at 5:14:03 AM UTC-8, chad altenburg wrote:
> On Sunday, December 29, 2019 at 4:34:57 PM UTC-8, Arne Vajhøj wrote:
> > On 12/27/2019 11:13 AM, Eric Douglas wrote:
> > > not sure what 'off by one' issues are
> > 
> > Usually this means code like a[i+2] that should have been either
> > a[i+1] or a[i+3].
> > 
> > Wikipedia has some slightly different examples 
> > https://en.wikipedia.org/wiki/Off-by-one_error
> > but I associate it with the array index calculation being one off.
> > 
> > BTW, such an error happening is actually revealing a code smell. Data
> > structures and code logic should be written so that it is very difficult
> > to make such an error.
> > 
> 
> And I don't know of any sane and rational method to go about doing it. It goes like this. Internally, the data has the format like
> 
> [StartHour, StartMinute, StartAmOrPm, EndHour, EndMinute, EndAmOrPm]
> 
> Now what happens say I want to add a flag to switch this data because I want to take the day off. Yes, I can clear the data. But I would still need an additional piece of data added to this format so when if I traverse of this list, the app knows to do whatever when it sees the "day off" flag.
> 
> Likewise, what happens if I want to take a day off, and still get paid? Maybe I want to do this because I want to use some paid personal time (PTO) off before the end of the year. This is because my PTO might not carry over to the following year.

And here is the other winner when dealing with memory leaks and off by one errors. I use the Google Calendar API to check for the current day. The days representing like Calendar.SUNDAY, Calendar.MONDAY, …

The problem is that is if Google changes integer value for something like Calendar.SUNDAY on the next API update, then some of my code breaks because the value will be off by at least one. Do you have any ideas how I can prevent something like this from happening?

You might say, well "Just change APIs". But like a lot of systems[1], the API is bounded to the platform like a hooker is bounded to her pimp. Yeah, in cases you could break the bond, but the entire process is a pain in the ass, and in both cases, there could be some unforeseen consequences.

[1]Other systems to that come to mind is the Salesforce Bayeux Protocol (API) used on something like Heroku and parts of the Oracle Cloud Platform.

[toc] | [prev] | [next] | [standalone]

#39246

On Mon, 30 Dec 2019 05:46:06 -0800, chad altenburg wrote:

> And here is the other winner when dealing with memory leaks and off by
> one errors. I use the Google Calendar API to check for the current day.
> The days representing like Calendar.SUNDAY, Calendar.MONDAY, …
>
> The problem is that is if Google changes integer value for something
> like Calendar.SUNDAY on the next API update, then some of my code breaks
> because the value will be off by at least one. Do you have any ideas how
> I can prevent something like this from happening?
>
DO NOT use you own made-up constants: always use the ones defined by the 
package provider - in this case Calendar.SUNDAY, etc.

If you've 'included' classes that define such constants so you can create 
class instances, call their methods, etc. then by definition any publicly 
declared constants they contain are also available for you to use in your 
code.

  

-- 
Martin    | martin at
Gregorie  | gregorie dot org

[toc] | [prev] | [next] | [standalone]

#39250

On 12/30/2019 8:46 AM, chad altenburg wrote:
> And here is the other winner when dealing with memory leaks and off
> by one errors. I use the Google Calendar API to check for the current
> day. The days representing like Calendar.SUNDAY, Calendar.MONDAY, …
> 
> The problem is that is if Google changes integer value for something
> like Calendar.SUNDAY on the next API update, then some of my code
> breaks because the value will be off by at least one. Do you have any
> ideas how I can prevent something like this from happening?

Don't worry about it.

Calendar.Xxxday are static final fields. And due to how they are
treated in Java, then there is no way Oracle/JCP will ever change the
values.

Arne

[toc] | [prev] | [next] | [standalone]

#39253

On 12/30/2019 3:11 PM, Arne Vajhøj wrote:
> On 12/30/2019 8:46 AM, chad altenburg wrote:
>> And here is the other winner when dealing with memory leaks and off
>> by one errors. I use the Google Calendar API to check for the current
>> day. The days representing like Calendar.SUNDAY, Calendar.MONDAY, …
>>
>> The problem is that is if Google changes integer value for something
>> like Calendar.SUNDAY on the next API update, then some of my code
>> breaks because the value will be off by at least one. Do you have any
>> ideas how I can prevent something like this from happening?
> 
> Don't worry about it.
> 
> Calendar.Xxxday are static final fields. And due to how they are
> treated in Java, then there is no way Oracle/JCP will ever change the
> values.

     ... and even if they did, a simple recompile would fix it without
even one character's worth of changes to the source.  (Provided you've
followed Martin Gregorie's advice, of course.)

-- 
esosman@comcast-dot-net.invalid
Three hundred eighty-seven days to go.

[toc] | [prev] | [next] | [standalone]

#39256

On 12/30/2019 3:55 PM, Eric Sosman wrote:
> On 12/30/2019 3:11 PM, Arne Vajhøj wrote:
>> On 12/30/2019 8:46 AM, chad altenburg wrote:
>>> And here is the other winner when dealing with memory leaks and off
>>> by one errors. I use the Google Calendar API to check for the current
>>> day. The days representing like Calendar.SUNDAY, Calendar.MONDAY, …
>>>
>>> The problem is that is if Google changes integer value for something
>>> like Calendar.SUNDAY on the next API update, then some of my code
>>> breaks because the value will be off by at least one. Do you have any
>>> ideas how I can prevent something like this from happening?
>>
>> Don't worry about it.
>>
>> Calendar.Xxxday are static final fields. And due to how they are
>> treated in Java, then there is no way Oracle/JCP will ever change the
>> values.
> 
>      ... and even if they did, a simple recompile would fix it without
> even one character's worth of changes to the source.  (Provided you've
> followed Martin Gregorie's advice, of course.)

It would break binary compatibility for no good reason. That is a no no
in my book.

Recompile may not fix Chad's problem though. The description is not that
clear but if the problem is related to using week days as array index,
the recompile may not fix the problem. If that is indeed the case then
using week days as keys in a Map would be safer.

Arne

[toc] | [prev] | [next] | [standalone]

#39257

On Monday, December 30, 2019 at 3:51:18 PM UTC-8, Arne Vajhøj wrote:
> On 12/30/2019 3:55 PM, Eric Sosman wrote:
> > On 12/30/2019 3:11 PM, Arne Vajhøj wrote:
> >> On 12/30/2019 8:46 AM, chad altenburg wrote:
> >>> And here is the other winner when dealing with memory leaks and off
> >>> by one errors. I use the Google Calendar API to check for the current
> >>> day. The days representing like Calendar.SUNDAY, Calendar.MONDAY, …
> >>>
> >>> The problem is that is if Google changes integer value for something
> >>> like Calendar.SUNDAY on the next API update, then some of my code
> >>> breaks because the value will be off by at least one. Do you have any
> >>> ideas how I can prevent something like this from happening?
> >>
> >> Don't worry about it.
> >>
> >> Calendar.Xxxday are static final fields. And due to how they are
> >> treated in Java, then there is no way Oracle/JCP will ever change the
> >> values.
> > 
> >      ... and even if they did, a simple recompile would fix it without
> > even one character's worth of changes to the source.  (Provided you've
> > followed Martin Gregorie's advice, of course.)
> 
> It would break binary compatibility for no good reason. That is a no no
> in my book.
> 
> Recompile may not fix Chad's problem though. The description is not that
> clear but if the problem is related to using week days as array index,
> the recompile may not fix the problem. If that is indeed the case then
> using week days as keys in a Map would be safer.
> 

I could show you the GitHub link that has *all* the code for the engineering wonder. But I suspect that like most people, you would gasp in horror at the complexity and then criticize the parts of the code that were either auto generated by my IDE or the code that was lifted from the Android docs because the code represents "a best practice".

[toc] | [prev] | [next] | [standalone]

#39261

On 2019-12-30 14:46, chad altenburg wrote:
> And here is the other winner when dealing with memory leaks and off by one errors. I use the Google Calendar API to check for the current day. The days representing like Calendar.SUNDAY, Calendar.MONDAY, …
> 
> The problem is that is if Google changes integer value for something like Calendar.SUNDAY on the next API update, then some of my code breaks because the value will be off by at least one. Do you have any ideas how I can prevent something like this from happening?

Oh, that's easy. You just have to declare them final.

-- 
DF.

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | comp.lang.java.programmer

csiph-web