Maven: Nigeria -- Great when everything works together. But so easily corrupted.

ikp4succes:
Just use hashmaps tree maps and u could solve this easily..

Please go ahead Sir and show how you would solve it by posting your solution.

Sibrah:
Mr. OP, what you posted here isn't really a Java problem but a programing algorithm challenge. It can be done in virtually any language or even a pseudocode or flowchart will do.

Ok. The solution I have done is in Java. But if you want to attempt it using a different language then by all means go ahead. I would be interested to see a solution posted in C# or in any other language.

I tire for some programmers on NL.

@OP, do you expect someone here to do your whole assignment for you?

I suggest that you narrow down your query to a specific problem you are having trouble with. Include, what code you have written and what line of code or outcome that isn't working for you.

If you are having trouble understanding a certain concept then specify how much of it you do understand what exactly it is about the concept that you don't understand.

If you structure your question this way, then you will probably get answers that will actually help you.

But posting your whole assignment here and saying "Help Me" doesn't give anyone a place to start.
Unless of course you are willing to pay a programmer here to do it all for you. In that case, I'll let you know my fee

What many programmers fail to see is the bigger picture.

The lifespan of a good quality software application is anywhere between 10 - 15 years. Sometimes even much longer. I've built products at companies and gone back there 8 years later and the thing is still running and still making money for that company.

The thing is, it usually takes a team of developers between 6 months to 2 years to develop a software application depending on its size. If that application lasts 15 years, the original development period is actually just a small part of that lifecycle. The rest of the lifecycle is spent on application maintenance and upgrades.
If the code you developed initially was not designed and built in a maintainable fashion, then the remaining lifetime of the application will be difficult and expensive for the customer to maintain. Leading them to usually ditch your product for a better one and brand you as a poor developer.

So my point is that, although maintenance is easy to overlook during initial development, it crucially forms the largest part of a software's life so developers need to understand how to develop code that is maintainable in order to deliver a quality product.
And a good place to start is by having a good grasp of Design Patterns.

@bluetrails

You're absolutely right. You will need to recreate the matrices to achieve the effect of a counter-clockwise rotation.

No attempts yet.

Java heads where are you?

This opening is back on now...

This challenge is based on working with 2-dimensional arrays (or matrix). I've met a number of professional Java developers who simply failed this task and I've met at least one student who successfully completed it.

It isn't an easy task but I think it is a real of test one's ability to think as a programmer should.


BACKGROUND CONTEXT

A zero-indexed matrix A consisting of N rows and M columns of integers is given. It can be decomposed into two sets, called upper spiral and lower spiral. The decomposition proceeds as follows:

· remove the top row of the matrix and assign its elements to the upper spiral;

· if a non-empty matrix is left, remove the bottom row of the matrix and assign its elements to the lower spiral;

· if a non-empty matrix is left, rotate it counter-clockwise (so that the rightmost column becomes the top row) and repeat.

For example, consider matrix A consisting of 7 rows and 8 columns:

5  3  8  9  4  1  3 -2
4  6  0  3  6  4  2  1
4 -5  3  1  9  5  6  6
3  7  5  3  2  8  9  4
5  3 -3  6  3  2  8  0
5  7  5  3  3 -9  2  2
0  4  3  2  5  7  5  4

It can be decomposed into the following upper spiral:

5  3  8  9  4  1  3 -2
                     1
  -5  3  1  9  5     6
   7     3  2  8     4
   3                 0
   7  5  3  3 -9  2  2

and the following lower spiral:

4  6  0  3  6  4  2
4                 6
3     5           9
5    -3  6  3  2  8
5
0  4  3  2  5  7  5  4

THE CHALLENGE

Write a function:

class Solution { 
        public int solution(int[][] A) {
           // your code in here!
        }

}

that, given a zero-indexed matrix A consisting of N rows and M columns of integers, returns the sum of the elements that belong to the upper spiral of matrix A. The function should return −1 if the sum does not lie within the range [−100,000,000..100,000,000].

Assume that:

· N and M are integers within the range [1..1,000,000];

· the number of elements in matrix A is within the range [1..99,999,999];

· each element of matrix A is an integer within the range [−2,147,483,648..2,147,483,647].

For example, given matrix A consisting of 7 rows and 8 columns corresponding to the example above (i.e. A[0][0] = 5, A[0][1] = 3, A[0][2] = 8, A[1][0] = 4, A[2][0] = 4 etc.), the function should return 91, because

5 + 3 + 8 + 9 + 4 + 1 + 3 + (−2)
+ 1 + 6 + 4 + 0 + 2
+ 2 + (−9) + 3 + 3 + 5 + 7
+ 3 + 7 + (−5)
+ 3 + 1 + 9 + 5
+ 8
+ 2 + 3
= 91.


I have competed this task myself and I'll be posting my own solution in a few days time.

kambo:

YOu maintain that this is not a problem. I say it is a big problem. a sleeper problem that programmers
have gotten used to. But it is still a big problem.
As more sub packages and nested structures enter the program heirarchy the temptation to
write duplicate code will increase , the resentment to write that extra import statement will rise.
That's why ide's are so much an issue here , they mask the bad traits of a language.
An ide could just append the extra ,redundant import statement but better if the language design
were extended to eliminate those statements.

YOu still fail to see what i'm saying. YOu think i'm against using import statements and that i'm
saying what i say because i dont want to write import statements. That's missing the point by a wide
wide margin.
My point is, if global functionality were placed at the top of the heirarchy in a project ,
all members within the heirarchy will access this functionality naturally , they will still use
import statements for the non global functions.
In this case the top heirarchy would be the package construct.
it would hold the functionality , class Utility is created to hold, making the Utility class un necessary
except for providing services to objects outside the package.
Code creation would be simpler and neater. truer to real world oop relationship model.

Guy, don't over think it. There is no resentment to writing simple import statements and any developer worth their salt would much rather import a method and use it than re-write the whole method again. Anyone who would rather duplicate code than import a method doesn't know what he or she is doing.

I hear what you are saying Kambo. You want more flexibility. I get it. But putting global methods at the top of the package hierarchy instead of just using imports will make applications so flexible that they become more error prone and effectively force developers to over-think their method calls, for example: is the isNull method I am calling in my top end package or in my second to the top-end package? Oh, its in the top end one but I want to use the isNull in the second to the top end package so instead I'll call it by its fully-qualified name. But wait, my colleague has just added another isNull in the package below mine and that is the one I really need - but it is in the package below so I might have to move my code so it is below it... You can imagine the chaos that will follow and developers will definitely start duplicating code because they will want to be sure of what methods they are calling. Essentially, mistakes will be much easier to make because the structure will too flimsy. This is precisely the kind of problems that import statements are designed to solve. Create a public class - in any package or sub-package you like - put your global methods in there and then import it where you need it. Simple and structured. It couldn't be easier.

You can do anything you like if you wanted to write your own compiler, but smarter people than you and I already know how important proper structure is in programming languages. Too much flexibility and the quality of the applications will seriously suffer and the language will be dropped like a piece of hot coal.

kambo:
Are you insane vs have you heard of large software?

I've worked on applications with literally millions of lines of code and trust me you never, ever need to have 100,000 import statements. Even 1000 imports in one class is a complete joke and shows serious design issues.

kambo:
I said 100 000 sources in differnt subpackages - meaning the 100 000 (if the app is this large)
reside under 1 package - but they're distributed into different sub packages within the 1 package.
simple.
e.g
in java you have.
javax.swing; javax.swing.text; javax.swing contains javax.swing.text. javax.swing is a package that
contains subpackages and it may contain many sub packages which may contain in themselves sub packages etc and the total files in the main package - javax. could be large e.g 100 000
and all these 100 000 distinct files have only one way to solve global function needs. instantiation -
static referencing, for classes in same package ,else import for classes in differnt packages.
if javax as package held global functions - global to all the members in it. then some of the import statements would be reduced. because the global functions are "seen" by all the members.
less import statement, less code, globalisation issues solved.
I'm patiently going over the point i'm stressing . cuz you're confusing issues.

and like I said, if you have multiple classes in a packages and you just don't feel like writing full import statements for each class because your fingers are tired from posting on NL then use a wildcard. Better still, use a proper IDE that imports stuff for you automagically.

The bottom line is - this is not a problem! OK. Java has issues that have serious effect on development. Issues like type conversion, null referencing, memory leaks and others. These are issues. Suggesting that writing import java.util.List; is an issue just because you don't like to write import statements does not qualify it as important. It is really just your personal gripe. Why if Oracle considered every personal whim of every developer out there then they would be too inundated to put out any releases at all.

Besides, if you have an application where you have to do thousands of import statements in a single class then that is enough to let you know that your application is seriously flawed and you should really look at redesigning and re-factoring into a cleaner code base.

kambo: 100 000 source files in different subpackages will requires 100 000 import statements.
sorry problem not solved.

import java.io.File;
public class MotherC{
public void doNada(){}
}
------
class childC extends MotherC
{
public void doNada(){
File f = new File(".";
File[] frr = f.listFiles();//
.....
}
}

compiler error:

childC.java:6 error: cannot find symbol
File f = new File(".";

 childC 

is extending

MotherC

and is in same package as

MotherC

To fix the error i have to include the same import statement in the subclass-

childC

each class/source file must have its own import statement.
2 source files, 2 import statements.
100 000 files, 100 000 import statements. 100 000 extra lines of code.
and import is the only way solve the need for global functions in clases in sub packages.
global functions/fields would reduce number of import statements written for classes in subpackages.
summary:
for non global functions - use import,static fields etc.
for global functions/fields - something more than import is required that saves code and is philosophically sound (oop wise).

You want to have 100,000 source files in 100,000 different sub-packages? Are you insane??

You're right. The problem isn't solved. Because the only problem you have here is extremely terrible design.

kambo:
@jeff
its a big issue.
The import wrk around is unwieldy for large code files .
And do lamguage improvements all require language rewrite. Easy on d exaggeration.
Java 8 is like nothing you've seen bf ,improvement wise. The changes to the language are deep and in one case theyre breaking with legacy code ,did this necessitate a re write?
The idea i air will not break legacy code . It just anoda tool and extension and a minor one at tht.
Infact,unlike genercs where compiler warns about usg untyped collection this concept if implemented wud generate nothg because it is just like inheritance in implementation.
The issue isnt about designing software better or messg with classpath but makg usg a language to express concepts easier.
If a programmer has 100 000
source files in a package and its sub packages requirg a set of typical services ,it is far better to let the servce trckle down to them by virture of theyre being under a particular umbrella , than by writg 100k import statements or creatg some form of often artificial inheritance.
It's simple common sense.

You don't have to write 100k import statements. Just use a wildcard silly.
Eg import java.util.*

And before you mention memory, using the wildcard is memory efficient. Problem solved. Again

Jetland: i need d help of anyone who can give me a link to download free netbeans Or eclipse IDE.

http://lmgtfy.com/?q=netbeans

^^^

So let me get this straight, you are proposing a major rewrite of the Java language all because you don't want to write "import somePkg.A" ??
And you will STILL have to use full canonical names to avoid clashes which is effectively what an import is doing but in a more structured way.

That isn't a very good solution, furthermore it attempts to solve a problem that doesn't even exist. I think there are real weaknesses in Java like it's poor null reference handling, weak type conversion and potential memory leaks.
An import statement however is not a bad thing and If yr app is designed well, you will never ever have to look at classpath manipulation to access other packages in the same application.

@kambo

..sign.

What you said is wrong on a number of different levels but I can't tell if you are actually stating what is plainly incorrect or the way you are putting your points across makes them all seem incorrect.

I would ask you to explain further but I get the feeling that if I did your next post may sound even more confusing. What you need to do is put forward your point in a more concise manner. Just a few lines of text and a few lines of solid example code to illustrate the point and then perhaps we can have a technical discussion. Until then, I haven't got the time to spend working out what your post is trying to say and still run the risk of not getting it.

Intelligence isn't about explaining a simple concept in a complicated way, It's about explaining a complicated concept in a simple way.
Try it.

@kambo
Java does not have globally defined functions. It uses Import statements which is a more concise solution. It creates clarity and avoids confusion. For example, imagine you had a globally defined method called isNull() and you bring in some 3rd party code which also has a globally defined utility method called isNull(). When some code calls isNull() which one of the two global methods will it use? The first one on the stack? Then you'll need to get into classpath ordering at the application level to ensure that the right functionality is used at the method level. The result would unfortunately be chaotic.

So simple Import statements give very clear and strong references to classes that you want to use and with these, you can use as many different methods with the same name as you like in the same class.

Also, your write up about messing around with application level classpath issues to get around writing simple Import statements makes me wonder if your priorities are about building a solution or just experimenting with java.

^^^^^^^^^

Assuming your packages are all part of the same project then a simple Import statement will solve all your problems.

There is a lot of stuff in your post but if I understand you correctly, you do not like the fact that have to make a class or a method Public to access it from another package.
Because if your isNull method was

public static

when you will avoid wasting memory and it would be accessible to all other classes in your application.
Correct me if I'm wrong but making your class or method public seems to be your beef. Right?

Well I think you have more of a design issue there than anything else. Java is designed to be flexible. There are times when you need a class to be public and other times you may not. If you have a simple utility method like

isNull(Object o) 

that you want to use across your application then what is the point of making it non-public? You want it to be public so you can access it public-ly. That is the whole point.

If however, your

isNull

method is in a class that you have made non-public (protected etc) and you want other classes to use this method, then it has no business being in a non-public class. Create a public utility class and put it in there. Done.

As for using Import statements, there is nothing ugly or verbose about that.

sabams08:


I will be presenting it as my work

Then perhaps you should do it yourself. What's the point of graduating with a qualification in Computer Science and not having actually done the computer science project yourself. Unless you want to be a graduate on paper only.

Will you be presenting this work to the university as your own?

2buff: @kambo
... It might be fun coding without an ide as a hobby, but it adds absolutely no value to the business...and in fact is detrimental to business value and team synergy. When you get to this point of professional maturity in the craft, then you will understand...

Absolutely true!!

Kambo has obviously grown very fond of using Notepad++ to write code and I can see will say anything to justify that. Well if you want to use an axe to cut down trees then I won't say its wrong. For me sha, I'll stick to my power-saw

So coming back to the topic of the thread, my power-saw of choice is the mighty Eclipse.

Javanian:

Can i know what a debugger can do that an out.println can't?

Step through every line of your code without you having to write a single line of extra out.print code
Inspect every local variable in the middle of a running program even ones that are not in the method that's running
Change the value of a local variable and then continue running from that point with the new value
Run through a method then go back to the beginning of the same method and step through it again

I could go on, but out.print and a debugger are two very different things.

kambo:

yes i can. And programmers were doing so bf d days of ide's.
First, wat is a debugger?
And how does the size of code affect a coders trouble shootg skills?
Notepad++ is just a programmer's editor. It doesnt do debugging.
You might as well say if you arent usg an ide you arent writg any real wrld code.
This is junk talk .
Wat constitutes industrial strenght code?
Mind you some famous apps were written in asm - no debugger. No ide.
Wat is a small app? Dyu think with your ide or algorithmically?
The best tools in d market wont save poor algorithms.
It seems you are a newbie in programmg. Go and grow up a bit bf gettg dogmatic and fanatical.
Ides are labour savg devices- nothg more nothg less.
Ides are prescriptve , most framewrks are thts y theyre so many out there cuz some1 who doesnt like doing things the prescribed way creates his own tool . Swearg by an opinion is narrow mindedness cuz tomorrow some1 will com out with a "better" way.

If you can't do somthg say so but dont assume every1 is as limited as you are.

Kambo! I think you need to kool down a little bit there. Although it is good to see that you are passionate about development, you are obviously taking this quite personally - but this is a technical discussion.

The fact is, we have all written programs in code editors like Emacs, VI, TextPad etc (trust me, I've been doing this for a long time) And if you were stubborn determined enough, you could write a fairly substantial amount of code in these. But, and it is a BIG but, in today's world of highly complex industrial strength software, you CANNOT develop a good quality product without a debugger. And in Java, the IDE's provide the debugging facility.

Saying you prefer not to use an IDE is like a tree-logger saying he prefers to use his axe instead of a power-saw. Sure he can still chop the trees down but it will take him much longer than his power-saw carrying colleagues and the quality of his chopped wood will really suffer.

As developers in 2013/14 we are no longer competing with foreign developers on algorithms or application functionality. We can build just as good as they can. What we are competing on now is quality and speed of completion. And with 95% of investment in software going to companies outside Nigeria, we are losing BIG TIME.
Developers need to stop trying to re-invent the wheel and use the best tools available to develop applications quickly and of better quality than foreign developers. Trying to shun tools that exist solely to make you write code quicker and better is in my view a serious step backwards.

kambo:
you only need to ask yourself how you ,as a programmer, can trouble shoot your program Without an ide.

If you haven't used a debugger then you are not writing any real industrial strength code. It's that simple. Perhaps for small apps that do basic things you may get away with it. But can you imagine writing a multi-threaded application that deals with millions of live financial transactions a day in Notepad++ ?? Without a debugger

Please don't try it and give Nigerian software developers a bad name o.

The best workman uses the best tools. It's that simple.

Anyone can learn how to program. But those with talent find it easy.

Eclipse is the sheez-nit!!

@kambo, I would love to see how you debug code using Notepad++. I would pay good money to learn how to do that

Java does have some good APIs covering Bluetooth development. Check out JSR 82 (javax.bluetooth) and Obex (javax.obex) APIs.

You'll be able to find a good beginner's tutorial here: http://www.oracle.com/technetwork/systems/bluetooth2-156149.html

Enjoy.

What version of Derby are you using? Earlier versions of Derby like 10.0 contain bug that sound like what you are experiencing. I believe it was fixed in version 10.2.1.6

https://issues.apache.org/jira/browse/DERBY-1173

It isn't difficult at all. You just need persevere and be committed. Download a free copy of the Sams Teach Yourself Java from here:
http://it-ebooks.info/book/2432/

Start from the very first chapter. It will guide you through all the basics from the very first step.

But remember, a good developer always finds a way to solve a problem. No matter what the problem is. Good Luck.

Unfortunately not. I need someone situated close to our client to offer them the support they need.

Are you a Java developer looking for a new full time job doing what you love?
Do you enjoy creating new software and solving complex problems?
Do you have at least one completed Java project (commercial or personal) under your belt?
Are you interested in being part of a start-up where your work is used in mission-critical software used live by users everyday?

If you answered yes to the questions above then you need to get in touch. We have one full time opening at our offices in Jos where you will be part of the ongoing development of our flagship product and support the software running at our client sites.
In return we offer good salary and bonus packages, your own office, mentoring from our UK based developer and career growth prospects.

If you are interested or would like more details contact me at:
Stayintouchwithandrew@gmail.com with your CV and details of your suitability for the role.

Please only apply if you have completed or being part of a team that has completed the development of at least one Java based application. A completed JEE application is even more desirable but not essential.