javacavemaps-developers Mailing List for Java Cave Maps
Status: Pre-Alpha
Brought to you by:
caverdude
Menu
▾
▴
javacavemaps-developers — Will be talk about packages, public classes and public methods
You can subscribe to this list here.
| 2003 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(7) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2004 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(1) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2008 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(39) |
| 2009 |
Jan
(79) |
Feb
(26) |
Mar
(8) |
Apr
(6) |
May
(4) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2010 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(1) |
Jul
(1) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Larry G. <jav...@ya...> - 2009-05-21 23:35:52
|
Well this list is for talk about the public API.. I realize we are not working on a (library, api, framework) In a sense we will be. For example I agreed based on prior discussion that the view should be plugable. This means that the model at least will be a framework or api. Sure, at this point there is not much to discuss really. Non the less, please review what we have going so far and post a comment to this list. Then we will comment on the comment. I will be looking at the source more over the next week and post some cmments myself. Debugging and integration and refactoring is the tough part of programming, reviewing and comenting shouldnt be so tough.
As far as public api goes.. yes things are made public in the case of libraries. But also within our own project so that classes in one package can see classes in any other package in the project. Otherwise everything could be made package private.
Larry Gray
la...@ar...
|
|
From: Larry G. <jav...@ya...> - 2009-05-14 06:27:14
|
I have been thinking about our release files when we get to that point. I feel we should release a single file with the Web App war file.. and 3 jar files.. Jar files for applet, application and web start app. In this way someone may download it and choose to use any of the 4. We can still post the latest applet and webstart app on our project web site each time we do a release.
Larry Gray
la...@ar...
|
|
From: Larry G. <jav...@ya...> - 2009-05-13 03:52:34
|
I felt we needed to approach the design of the public interface with a partial committee style. I certainly do not want to be designing the whole public api myself. And I also don't want it designed without discussion and coordination.
Larry Gray
la...@ar...
|
|
From: Larry G. <jav...@ya...> - 2009-05-02 04:33:53
|
I have simply put everything into a JTabbed Pane for now.. I think in time we will want the UI layout to be scripted so that anyone using the applet or application can have some options for the ui layout.
Larry Gray
la...@ar...
|
|
From: Larry G. <jav...@ya...> - 2009-04-24 03:04:38
|
Any of you guys that have looked at the source lately. Say something about the view. Hicsys will be assigened the view, model and controller packages.
Larry Gray
la...@ar...
|
|
From: Larry G. <jav...@ya...> - 2009-04-15 16:56:37
|
Well the part that is needing most attention right now is the View.. mainly the Menu and the JTabbedPane also a Stats panel which will be some code pulled from that ConrtolPanel. Who wants to be in charge of the view package and probably them model package as well?
Larry Gray
la...@ar...
|
|
From: Larry G. <jav...@ya...> - 2009-04-15 16:29:26
|
Welcome to the new Developers mailing list. Here we will discuss packaging, including what goes in core or components or utilites. We will discuss how best to use OOP to model the problem domain. We will discuss what public behavior is needed in the kinds of classes we want. Each of you will have two or more packages under your control. But this is just for organization. Anyone can be assigned any task if the peson who is assigned that task is not moving too fast and we need it done now. Again you will be writing the public Class, Interface and Enum definitions. You will be creating task for the programmers and yourself. You will receive task by the architects in reguards to patterns and re factoring. Anyone may join this mailing list. If someone gets rude then any of the moderators(developers) may remove their postings. Wish me luck with this idea. I'm simply trying to spread out the work load.
Thanks.
Larry Gray
la...@ar...
|
|
From: Larry G. <jav...@ya...> - 2009-04-12 21:10:46
|
Hey guys, I have been putting some thought into the organization of the project management. We now have one mailing list javacavemaps-developers I am going to make one called javacavemaps-programmers and javacavemaps-architects. I will select 8 of you right now to be moderators for the developers list. I will select 4 to be moderators for the architect list. These 4 will also be moderators on the developers list. The programmers list at least for now won't have moderators except for me. Anyway I expect anyone who is not a moderator on the developers list and architects list to be a member of the programmers list. None of the programmers will have to be members of the other two but you may if you like. However the moderators of the developers list will be doing the dicussion on that list and if they do not allow then no one else may post an entry to it. Same on architects list, only archtects may post to it, unless they decide to allow a
non architect posting. Anyone may post to the programmers list. The developers list will be used for dicussing which packages to make, and what public classses to make and what methods to make. In addition I will assign each of the 6 moderators on this list to have a section of the project which they are responsible for building the class definitions and interface definitions and enum definitions. The architects will merely watch for code smells, and watch for emerging patterns and determine refactoring task. I may divide the project into 4 parts for the architects. The 6 developers will be responsible for creating task and assigning them to programmers or to themselves. Architects will be respoinsible for creating refactoring task and assigning them to developers or themselves.
Any questions? Sound like a possible good plan? I am going to look at number of years with java to decide who would make better developers and architects. So I'm depending first on your honesty.
Larry Gray
la...@ar...
|
|
From: Larry G. <jav...@ya...> - 2009-04-02 15:33:08
|
The major task for administrators on a project would be to motivate the Programmers, Developers and Architects.. I would consider that I'm doing a good job if I can organize and motivate, though I do want to do some of the coding myself as I like programming too.
Larry Gray
la...@ar...
|
|
From: Larry G. <jav...@ya...> - 2009-04-02 14:51:52
|
Many hands make light work! a good saying..
Here is another,
"Work the pick, don't let the pick work you." A coal miner of the early
1900's I think this analogy or metaphor would be talking about rhythm
mostly, but also
managing scale/scope of the problem at hand to
alleviate stress. Some stress and pressure is good, this is why we
have this casetest area.
But when adding source
to the
actual tree we need to be careful, for one thing we don't need to be
creating throw away code which is disheartening. But if you do
something and that gets
removed from the project, remember that its always and forever part of the svn source tree as in history..
Also when you create example source in the casetest area you will most likely be the person adding that to the main source tree.
Larry Gray
la...@ar...
|
|
From: Larry G. <jav...@ya...> - 2009-03-31 05:41:16
|
I suppose what we need to do now is to get the applet, frame and webstart app working from within eclipse.
Larry Gray
la...@ar...
|
|
From: Larry G. <jav...@ya...> - 2009-03-26 01:59:31
|
You will see added to the specifications module a principles.xml and patterns.xml to understand those principles see google.. to understand those patterns see http://www.vincehuston.com/dp Or get some books on patterns. Many of the rules in elements of Java style are based on those principles. Thanks. Larry Gray la...@ar... |
|
From: Larry G. <jav...@ya...> - 2009-03-22 02:46:12
|
Well let me say a few things here. Back when I began programming we were using BASIC and programming was far simpler. To complicate it at that time
we had branching, loops and subroutines. IO was either console or file io. OOP complicates things a lot and why? Because its a effort to simply things. Ha-ha. Well on the most basic level it provides a good way to organize things. Objects organizes subroutines, funcitons and data. In Java this is called methods and fields. Packages organze groups of objects. Api's organize groups of packages. Beyond this organization or grouping is something called
patterns or industry standards or formally recoginzed ways to group things. As we begin this software we will not mess with patterns to much. We will no
fix the problem until we have the problem. Paterns should emerge over time. So in starting we will simply group things the best way we can. This idea
of the core and then the components that the sf user wags had was good, I adpated to that. There is also this concept of Aspect Oriented Programming, there is also Functional Programming. More high level concepts. We won't mess with those but I do see how there could be some room for those concepts even in an OOP language like Java. Other methodologies I've recently heard of, RUP, Rational Unified Process and SCRUM whatever that is. I think some of the folks that didnt' stay on this project wanted to do things the old way with huge up front planning and design. Well anyway we won't do things that way. So right now it boils down to finding the core abstractions. OOP atempts to model the problem. In our problem we have these core components to model.
Mapping
1. Line
2. Room
3. Branch
4. Survey
5. Survey group
6. Cave
7 Cave group
Unfortunaly or forunatly however you look at it. We have 4 methods of deployment to complicate things. I could simplify by saying
lets just do the GUI application. But I wanted the greater chances of having our application appreciated by a wider audiance.
1. Application
2. Applet
3. Webstart
4. Webapp
We were basically working on #1 in the first list and #1 #2 #3 of the 2nd list.
We have the basic components already made we just need to shape things up a bit and start putthing things together.
Larry Gray
la...@ar...
|
|
From: Larry G. <jav...@ya...> - 2009-03-22 00:47:13
|
email will make this XP methodology work out. We must use email. thanks.
Larry Gray
la...@ar...
|
|
From: Larry G. <jav...@ya...> - 2009-03-22 00:46:18
|
The only thing anyone on this project should apologize for ever is in not sending emails to let us know what is going on with you. Weekly or bi weekly emails would be nice.. If you get tied up let me know, and let me know when you may have time again.
Larry Gray
la...@ar...
|
|
From: Larry G. <jav...@ya...> - 2009-03-21 21:39:58
|
http://www.eclemma.org/ There is an update site link.. this will show which code has been unit tested and which code has not in eclipse. Larry Gray la...@ar... |
|
From: Larry G. <jav...@ya...> - 2009-03-18 22:36:14
|
What are you guys thinking right now about the project?
Larry Gray
la...@ar...
|
|
From: Larry G. <jav...@ya...> - 2009-03-18 22:33:50
|
I discovered that I had forgotten that Test first is a part of XP. Beginning with the next iteration we will test first.
Larry Gray
la...@ar...
|
|
From: Larry G. <jav...@ya...> - 2009-02-20 20:47:45
|
Well I have the parsers reading from Files, Resource or String for FixedWidth, Delimited and CSV.. check out the case2 under casetest and caverdude..
Glad thats done, I can now move on to other iteration task.
Larry Gray
la...@ar...
|
|
From: Larry G. <jav...@ya...> - 2009-02-15 06:43:59
|
Take a look at CSVParser and FlatFileModel
I have not yet tested these two classes. Hopefully the logic will work if you test them. I think the FlatFileModel will be a great "Duct Tape" type of class.
Larry Gray
la...@ar...
|
|
From: Larry G. <jav...@ya...> - 2009-02-14 03:16:54
|
I have begun to prepend several capital letters to task names..
PDA in that order.. PD or DA or PDA or P D or A with a : space then the name.
P means programmer skill level required.
D means developer skill level required.
A means either consult an architect(admin's) or patterns or architect skill level required.
Also I means it will be an Iteration task. If it is not 100% complete then it is a current Iteration task.
C means it is a case test for the sand box area. Style will not be enforced. Only rule is that it must compile. Also the Description will begin with the key words CASE TEST colon and space.
This should give those looking at the task a better idea about whether or not they should give it a try.
Thanks.
Larry Gray
la...@ar...
|
|
From: Larry G. <jav...@ya...> - 2009-02-12 12:51:44
|
XP might imply writing a lot of code fast by its name. The funny thing is I had not looked at the methodology in that way. What impressed me most about it was the fact that it would keep me or a team from trying to carry load that would be too heavy for me or a team. XP should say that you increase the work load to only that of which the situation would imply that you should.
I suppose non XP folks would think that the metholology means getting a lot done very quickly. But XP says, yes but within reason.
Larry Gray
la...@ar...
|
|
From: Larry G. <jav...@ya...> - 2009-02-07 20:30:04
|
I believe in striving for perfection, you can't ever get there but you try anyway. The style guide and standards other guides for writing code like effective Java, and the XP methodology would be something that we strive for. It takes practice.
Larry Gray
la...@ar...
|
|
From: Larry G. <jav...@ya...> - 2009-02-07 18:57:47
|
XP is not about micro management, its about communication and coordination. Adjustments to task, scale and scope can reduce the feelings that a developer may have that he is under dictatorial micromanagement.
But this does not mean removing the ceiling for scope/scale. And about granularity as I call it and this idea of that removing more source than you are writing means you are on the right track. This applies to number of classes, methods, interfaces and packages in use as well. Precise, concise, well defined solutions. Of course this
takes time to mature or develop.
Larry Gray
la...@ar...
|
|
From: Larry G. <jav...@ya...> - 2009-02-07 18:23:39
|
We now not only have a good way to read in various types of data files, we also have more ways to store configurations.
I only begun moving the logic(implementation) from the casetest caverdude.case1 to the actual project source I started to work on the CSVParser but I now am out of time so I'll get to it again in a day or so.
On the next iteration we would begin working on formatters for writing the datamodels back to files. java.util.Formatter. Also the Pattern class documentation has a great breakdown for how to build regex strings.
Take a look at how I created the regex patterns in CSVParsing.java interface.
Larry Gray
la...@ar...
|
2 messages has been excluded from this view by a project administrator.
