NXT :: descendant of Bitcoin - Updated Information

[jl777]

If you´ve read my PM, I am trying to help you build a core dev team...

Yes, I need to think about how this should be done. Before the source was public, the problem was how to decide who is trustworthy. Now that it is open, how do we decide who is good enough?

Companies conduct technical interviews. Those will filter out the completely ignorant, but for more experienced people it becomes difficult to judge who is better. I am also not confident in my own skills as an interviewer, and also some good people perform bad at interviews because of the stress and pressure to perform. Especially for an open source project, I don't feel doing interviews is the right approach.

For paid developers, we could consider trial projects, which they would do on their own fork of the repository, and if at the end we like the code and integrate it into the main repository, we accept them as paid developers. This would mean they would have to spend a few weeks without pay at first. Or, we can take the risk and do it as a one month paid contract, with the option of making it permanent. This would be something the NXTtechdevfund committee should discuss.

I would need to research how other open source projects decide who to accept and trust, e.g. how the linux kernel development is organized, and see if we can adopt their project management practices.

In terms of skill set, being a very good Java developer is the only requirement. The code does not depend strongly on any specific tool or library. We use a database, so some familiarity with relational database and SQL is needed, but there are enough areas of the code one can work on without touching the database at first. We also use servlets and Jetty, so again familiarity with servlets and the http protocol would be helpful, but most Java developers already have that.

Good object-oriented design skills are essential. So is writing clean and maintainable code. For developers with main background in languages other than Java, I can tell immediately that Java is not their native language - I have seen lots of Java code that reads like C. The original BCNext code was very foreign too, so I had to rewrite lots of it. So for somebody coming from C/C++ background, if this is going to be their first Java project, they would need to learn a lot, so that the code they add actually reads like Java.

In addition to Java developers, and in fact much more urgently, we need a good cryptographer. This person doesn't even need to be that fluent in Java, the language background wouldn't matter (well, he should at least be able to read and understand the Java code). But I don't have much cryptography background myself, so this is an area where we currently lack skills, especially after the departure of BCNext.

Thank you very much for your detailed answer!

"For paid developers, we could consider trial projects, which they would do on their own fork of the repository, and if at the end we like the code and integrate it into the main repository, we accept them as paid developers. This would mean they would have to spend a few weeks without pay at first. Or, we can take the risk and do it as a one month paid contract, with the option of making it permanent. This would be something the NXTtechdevfund committee should discuss.

I would need to research how other open source projects decide who to accept and trust, e.g. how the linux kernel development is organized, and see if we can adopt their project management practices."

Give the applicant a real life scenario to work on. Something that has to be done for Nxt. A small part of a bigger task. So you can assess if he/she is good enough to be in the core dev team.

"In addition to Java developers, and in fact much more urgently, we need a good cryptographer."

Is that the same msin is working on with the review of the code? Or we need a cryptographer in our core dev team? Do you (or anyone else) have a suggestion whom we should approach?

I would be happy to come up with test Java projects for someone else to do

I could pay some amount of NXT upfront to reduce the risk for the new applicant, as long as we have reason to believe that he can do the job. Then I will need the Techcommittee to deal with any permanent arrangements and completion bounties.

Probably a good idea to have a good cryptographer on retainer or at least halftime. If the community can provide adequate testing, then that frees up more funds to pay the cryptographer. I dont think it has to be a big name guy, as long as he can do the crypto math competently, that is the key. Someone who can actually understand stuff like https://bitcointalk.org/index.php?topic=277389.0

James

[jl777]

Thanks Wesleyh! It looks great.

What I notice at start is the black bar at the bottom. It's not well designed like the rest of the screen. (black and white)

The second thing is; "Downloading blockchain.."
I want to see how much I already have downloaded so I can estimate how much I still have to wait.

It would be better if you can manage to add Estimate download time, or '5 minutes left' to download the blockchain.. Something like that.
Because now I don't know if I really downloading. Maybe it's stuck somewhere at a block.

Yes, black bar will be redesigned. Or removed.

About blockchain downloading, I don't think there is a way to know how long to go still. I guess I could compare last block to current time though, and do an approximation based on 1 block per minute?

I can help with completion time estimate algos. I will PM you

James

[Eadeqa]

Well, you can do everything whilst it's downloading the blockchain, of course you'll only get your balance once it reaches the correct block.
It opens NRS in the background, yes, locally.

Does it shut down NRS when you close it?

Yes.

Cool. You should add some kind of random password generator for creating new accounts, and then it should be distributed with all new NRS releases as a default client

[wesleyh]

Well, you can do everything whilst it's downloading the blockchain, of course you'll only get your balance once it reaches the correct block.
It opens NRS in the background, yes, locally.

Does it shut down NRS when you close it?

Yes.

Cool. You should add some kind of random password generator for creating new accounts, and then it should be distributed with all new NRS releases as a default client

Not sure if there is a good and secure javascript.random available - However if you open the app and choose register new account, (new users will probably do this although they could just login), then it requires special characters, minimum length, etc.

[Jean-Luc]

I have also sent the html interface to jean-luc, hopefully it will be in the next version (it is in this NxtWallet.exe already)

I will not have time to make another release until Sunday at best. For now, people should install Wesley's client manually.

[Fatih87SK]

Thanks Wesleyh! It looks great.

What I notice at start is the black bar at the bottom. It's not well designed like the rest of the screen. (black and white)

The second thing is; "Downloading blockchain.."
I want to see how much I already have downloaded so I can estimate how much I still have to wait.

It would be better if you can manage to add Estimate download time, or '5 minutes left' to download the blockchain.. Something like that.
Because now I don't know if I really downloading. Maybe it's stuck somewhere at a block.

Yes, black bar will be redesigned. Or removed.

About blockchain downloading, I don't think there is a way to know how long to go still. I guess I could compare last block to current time though, and do an approximation based on 1 block per minute?

I can help with completion time estimate algos. I will PM you

James

Thanks!

It doesn't need to be perfect. An estimate is fine by me!

[abctc]

Could somebody sent TestNxt to the  ....

- if someone needs testNXTs - ask them here: https://forums.nxtcrypto.org/viewtopic.php?f=2&t=832&p=4237#p4237

[pr65536]

First of all, Keep up with the great work!

I'm a newbie here but I would like to give you my two cents...
I believe that NXT has all the potential to become the next big thing. I see a great idea and I see great people working on it. I see also a great community that is forming around it.
The only problem is that for new people like me is very difficult to follow and join. There is this huge megathread that is growing faster than my reading capabilites. In this thread there is everything: from technical development discussions, to new software announcements, newbie opinions, complaints, philosophical discussions and everything else...
This is great, but frankly speaking, is not optimal. It end up that people just trow in it their opinion but without listening really at what other are saying.

My practical proposal: why not to split this thread in different threads? One for the technical/developers, one for the marketing, one for the newbie, etc.?

Or maybe there are already some different channels? (in this case, please point out where)
Cheers

[Eadeqa]

Well, you can do everything whilst it's downloading the blockchain, of course you'll only get your balance once it reaches the correct block.
It opens NRS in the background, yes, locally.

Does it shut down NRS when you close it?

Yes.

Cool. You should add some kind of random password generator for creating new accounts, and then it should be distributed with all new NRS releases as a default client

Not sure if there is a good and secure javascript.random available - However if you open the app and choose register new account, (new users will probably do this although they could just login), then it requires special characters, minimum length, etc.

You can use random mouse movement to create pretty secure password.

Copy their code https://www.bitaddress.org

[wesleyh]

Or like Bitcoin wallets with a green bar that shows the progress of downloading the blockchain.

Thanks!

Don't get offended or something. I'm just being a critical end user. Great work!

Not offended at all, I need and appreciate the feedback

[instacalm]

My practical proposal: why not to split this thread in different threads? One for the technical/developers, one for the marketing, one for the newbie, etc.?

Hi pr65536,

https://forums.nxtcrypto.org

[wesleyh]

You can use random mouse movement to create pretty secure password.

Copy their code https://www.bitaddress.org

thanks, will check it out.

[jl777]

My practical proposal: why not to split this thread in different threads? One for the technical/developers, one for the marketing, one for the newbie, etc.?

Hi pr65536,

https://forums.nxtcrypto.org

also http://www.nxtcoins.nl/bitcointalk-threads/ is quite useful

[wesleyh]

Gotta go, be back in 8 hours or tomorrow. Keep feedback, bug reports, etc coming. You can also PM me.

[verymuchso]

I did my research on random string generator libraries, it seems apache RandomStringUtils is not compromised.

Why aren't you using SecureRandom random = new SecureRandom()?

Simpler version from web

char[] allowedCharacters = {'a','b','c','1','2','3','4'};

SecureRandom random = new SecureRandom();
StringBuffer password = new StringBuffer();

for(int i = 0; i < PASSWORD_LENGTH; i++) {
    password.append(allowedCharacters[ random.nextInt(allowedCharacters.length) ]);
}

I don't believe I know better than the people from Apache who made that library.
That library is used in 1000s of production systems. You should not reinvent the wheel.

You are right about the difference between SecureRandom and Random, in the code I posted it does however not make sense to use SercureRandom. If you believe it does please explain why it does make sense in the code I posted.

http://www.docjar.com/html/api/org/apache/commons/lang/RandomStringUtils.java.html

They use java.util.Random

Where do you see SercureRandom used by RandomStringUtils?

I did not say they used SecureRandom in RandomStringUtils. What I did was look for ways to generate the safest possible passphrases and RandomStringUtils was mentioned and seemed to be used the most. It comes as a surprise that they do not use SecureRandom, if this in fact is unsecure this would mean that numerous production systems are at risk, which might even be the case who knows.

You started your argument by saying Random should not be used, since Random was used in the piece of code I posted I assumed you were talking about the random number between 70 and 90 for the password length, for which it makes no sense to use SecureRandom.

I do believe Apache should use SecureRandom. Looking at my code I also believe the seed string of characters used should not be a fixed string, it should be random as should your 'allowedCharacters' variable in the sample you posted.

The site where you can generate a passphrase with your mouse is really cool, it does however not work for people without a mouse.

[Jean-Luc]

Of course I hope the apache RandomStringUtils internally uses SecureRandom, this is where it would matter.

It doesn't

http://www.docjar.com/html/api/org/apache/commons/lang/RandomStringUtils.java.html

You are right. Maybe he should directly call the method that also takes a Random as a parameter, and pass it his own instance of a SecureRandom.

[martismartis]

Could somebody sent TestNxt to the  ....

- if someone needs testNXTs - ask them here: https://forums.nxtcrypto.org/viewtopic.php?f=2&t=832&p=4237#p4237

Hi, I'm not registered in forums.nxtcrypto.org , here is my church, where I get all information I need Still need some test NXT to 13965125640011039998

[igmaca]

If you´ve read my PM, I am trying to help you build a core dev team...

Yes, I need to think about how this should be done. Before the source was public, the problem was how to decide who is trustworthy. Now that it is open, how do we decide who is good enough?

Companies conduct technical interviews. Those will filter out the completely ignorant, but for more experienced people it becomes difficult to judge who is better. I am also not confident in my own skills as an interviewer, and also some good people perform bad at interviews because of the stress and pressure to perform. Especially for an open source project, I don't feel doing interviews is the right approach.

For paid developers, we could consider trial projects, which they would do on their own fork of the repository, and if at the end we like the code and integrate it into the main repository, we accept them as paid developers. This would mean they would have to spend a few weeks without pay at first. Or, we can take the risk and do it as a one month paid contract, with the option of making it permanent. This would be something the NXTtechdevfund committee should discuss.

I would need to research how other open source projects decide who to accept and trust, e.g. how the linux kernel development is organized, and see if we can adopt their project management practices.

In terms of skill set, being a very good Java developer is the only requirement. The code does not depend strongly on any specific tool or library. We use a database, so some familiarity with relational database and SQL is needed, but there are enough areas of the code one can work on without touching the database at first. We also use servlets and Jetty, so again familiarity with servlets and the http protocol would be helpful, but most Java developers already have that.

Good object-oriented design skills are essential. So is writing clean and maintainable code. For developers with main background in languages other than Java, I can tell immediately that Java is not their native language - I have seen lots of Java code that reads like C. The original BCNext code was very foreign too, so I had to rewrite lots of it. So for somebody coming from C/C++ background, if this is going to be their first Java project, they would need to learn a lot, so that the code they add actually reads like Java.

In addition to Java developers, and in fact much more urgently, we need a good cryptographer. This person doesn't even need to be that fluent in Java, the language background wouldn't matter (well, he should at least be able to read and understand the Java code). But I don't have much cryptography background myself, so this is an area where we currently lack skills, especially after the departure of BCNext.

Thank you very much for your detailed answer!

"For paid developers, we could consider trial projects, which they would do on their own fork of the repository, and if at the end we like the code and integrate it into the main repository, we accept them as paid developers. This would mean they would have to spend a few weeks without pay at first. Or, we can take the risk and do it as a one month paid contract, with the option of making it permanent. This would be something the NXTtechdevfund committee should discuss.

I would need to research how other open source projects decide who to accept and trust, e.g. how the linux kernel development is organized, and see if we can adopt their project management practices."

Give the applicant a real life scenario to work on. Something that has to be done for Nxt. A small part of a bigger task. So you can assess if he/she is good enough to be in the core dev team.

"In addition to Java developers, and in fact much more urgently, we need a good cryptographer."

Is that the same msin is working on with the review of the code? Or we need a cryptographer in our core dev team? Do you (or anyone else) have a suggestion whom we should approach?

I would be happy to come up with test Java projects for someone else to do

I could pay some amount of NXT upfront to reduce the risk for the new applicant, as long as we have reason to believe that he can do the job. Then I will need the Techcommittee to deal with any permanent arrangements and completion bounties.

Probably a good idea to have a good cryptographer on retainer or at least halftime. If the community can provide adequate testing, then that frees up more funds to pay the cryptographer. I dont think it has to be a big name guy, as long as he can do the crypto math competently, that is the key. Someone who can actually understand stuff like https://bitcointalk.org/index.php?topic=277389.0

James

I think in the forum of keepass you can get to locate a good cryptographer
http://sourceforge.net/p/keepass/discussion/329220/

[landomata]

Give the applicant a real life scenario to work on. Something that has to be done for Nxt. A small part of a bigger task. So you can assess if he/she is good enough to be in the core dev team.

"In addition to Java developers, and in fact much more urgently, we need a good cryptographer."

Is that the same msin is working on with the review of the code? Or we need a cryptographer in our core dev team? Do you (or anyone else) have a suggestion whom we should approach?

The Nxt Mobile Applications Company will pay 100,000 Nxt to the Java Dev who successfully implements SERVICE PROVIDER FEATURE into Nxt.

If he is successful then he can become a part of the Dev team.

So to repeat we will pay the bounty for this real life project.

[Jean-Luc]

Give the applicant a real life scenario to work on. Something that has to be done for Nxt. A small part of a bigger task. So you can assess if he/she is good enough to be in the core dev team.

Realistically, somebody faced with unfamiliar code cannot just jump in and start adding features. Even if he succeeds in doing it, it will look like a patch, an if/else hack, because he would be missing the big picture at first.

In a real company, a new programmer usually starts by just fixing bugs, for a week or two. Then, maybe start working on a feature that has already been designed and some skeletal work has been done on it. Or is very similar to an existing feature so that he can copy and follow the same design pattern (e.g., add a new transaction type which fits in the existing transaction types framework and doesn't need changing it). One would need at least a month of experience, getting familiar with the code, before being able to design and add a new feature all by himself.

"In addition to Java developers, and in fact much more urgently, we need a good cryptographer."

Is that the same msin is working on with the review of the code? Or we need a cryptographer in our core dev team? Do you (or anyone else) have a suggestion whom we should approach?

I don't think that guy had time to actively contribute to Nxt all the time. We don't really need a 100% full time cryptographer, but somebody who we can consult with regularly, and who can stay reasonably up to date with the current state of Nxt. Most of the time we don't need to make changes that require consulting a cryptographer, but when we do, we need to have somebody to refer to. Like, when considering changing the TF algorithm, or when deciding if there is any risk in accepting the proposed fix for the signature verification failing.