Tag: Sin categoría

What I’ll do this week (April 23)

--Originally published at Hermes's Blog

This week I plan to finish the test and have at least 70% of the api code covered. We already have all signup, login, profile and delete account functionality tested and passing. I tried to include the tests in the travis-ci build but it seems to have problems with the neo4j service, neo4j is throwing this error:

Uncaught error when processing result: Neo4jError: 140223444313984:error:140770FC:SSL routines:SSL23_GET_SERVER_HELLO:unknown protocol:../deps/openssl/openssl/ssl/s23_clnt.c:827

And I just don’t know why, should I just remove the https code when the code is being executed in travis? Maybe it’s because it does not find the key and certificate, but I don’t see why that would be the case, I’ll try again anyway.

Week 9 TO-DO

--Originally published at That Class Blog

We need new objectives!

And I need to update the code documentation and the README!

And that’s basically it. We don’t have anything more to do but to prepare for Friday’s presentation. I will publish at the end of the week what we plan to do the next week.

Cherio.

Miguel Montoya
Esperanto enthusiast
ʕ•ᴥ•ʔ

Week 9 TO-DO
“Old Objective” by wolfgangfoto (CC BY-ND). From https://www.flickr.com/photos/wolfgangfoto/2446866948/

 

What I’ll do this week (March 5)

--Originally published at Hermes's Blog

This week I’m not sure if we will be able to work in the project because it’s the Tarver Vertical (buuuh), but if we do, the most important thing to do right now (in the api) is to be able to split the bill of a pool. I think the best way to handle this is, when the pool owner says that the bill should be splitted evenly, take all current users and divide the bill evenly, the problem is that not all users have joined by this time, all I can do is that when a new user confirms the invitation the API will update all the relations to users in the pool to fit the new bill split. When the ower sets the bill split to custom it I think it should be able to set the amount that invited users should pay, that will require me to add a new relation from the pool to users where invited users have a special relation with the label `:invited`, just so it can tell the user how much is he spected to pay and then he can accept or reject this invitation.

The TODO list is as follows:

  • Pool owners need to split the bill, they should be given the options of spliting it evenly or with custom amounts (do we need to make sure that the total of all the custom amounts sum up to the total of the bill?).
  • Pool needs to specify who you should pay to, how much money do they owe or who payed more than necessary.
  • The only payment method available right now is cash, the pool owner should be the only one able to change the pool and relation to the pool properties.
  • Maybe invites should be visible through an interface in the app, I think that the best way to approach this is to create a new relation between the pool node and user node that indicates that he’s been invited. Because otherwise there is no other way to find out who you have invited, the email is send and after that it all depends on the user clicking the link.
  • We need a Facebook and Google login (I think this will be done by someone else).
  • User profile images are not critical (because we have default profile gravatars) but would be nice to have, we should store them somewhere outside the database, maybe store the path to the file in the node, or use an external service like Amazon S3.

 

What I’ll do this week (February 26)

--Originally published at Hermes's Blog

There are a lot of things that I’d like to do, I’ll enumerate them in order of importance.

  • Search pools and users, that implies that I need to create a way to query a regular expresion or at least the begining of one of their string properties. I also need to filter the pools by its `public` property.
  • Pool owners need to split the bill, they should be given the options of spliting it evenly or with custom amounts (do we need to make sure that the total of all the custom amounts sum up to the total of the bill?).
  • Pool needs to specify who you should pay to, how much money do they owe or who payed more than necessary.
  • The only payment method available right now is cash, the pool owner should be the only one able to change the pool and relation to the pool properties.
  • Maybe invites should be visible through an interface in the app, I think that the best way to approach this is to create a new relation between the pool node and user node that indicates that he’s been invited. Because otherwise there is no other way to find out who you have invited, the email is send and after that it all depends on the user clicking the link.
  • We need a Facebook and Google login (I think this will be done by someone else).
  • User profile images are not critical (because we have default profile gravatars) but would be nice to have, we should store them somewhere outside the database, maybe store the path to the file in the node, or use an external service like Amazon S3.

More testing – Week 6 TO-DO

--Originally published at That Class Blog

As I was saying in my previous blog, I have two new issues for this week. And the main focus of them are to enhance current features, not to implement new ones. I will explain them quickly.

More testing – Week 6 TO-DO
“Test drive of first production Tesla” by Robert Scoble (CC BY). From https://www.flickr.com/photos/scobleizer/2276152067

The first issue is to create a hook for the testing. This means, to create a dummy DB to stop pollution and requests to the main DB.

The second one is to update the testing script to include the new and future features.

Let’s work, work, work!

Miguel Montoya
Esperanto enthusiast
ʕ•ᴥ•ʔ

What I’ll do this week (February 4)

--Originally published at Hermes's Blog

This week I’ll translate what we had in the backend to use the new database. I think that should be my first priority. Then I’ll work in the implementation for the relations between the nodes. I’m a bit worried about the fact that I’m not testing the api for the database. Maybe later. Marco is now working on the frontend web application too. He defined the roles for everyone, since we are a big team.

What I did this week (January 29)

--Originally published at Hermes's Blog

This week I did’t finish the helper functions for neo4j but I have enough functionality so that we can start working developing the basic models and endpoints for the api. Now we can create models, restrict uniqueness of some fields and index the nodes in the database for fast lookups. With this functionalty we can start managing the users, and the money pools, we still need to implement the relations. There is no news for the mobile application.

What I’ll do this week (January 29)

--Originally published at Hermes's Blog

This week I hope to finish the Neo4j helper functions. Then I’ll rewrite the logic of the application server to use Neo4j, and then I want to create the money pool events and its relation with the users. I think that will give enough work to keep me bussy for the rest of the week (maybe part of the next week too). Right now the nodejs framework available for neo4j is only a driver that lets you create a session and execute text queries. I want to write a more friendly interface for the programmer to interact with the database, similar to mongoose but for Neo4j.

My ideas for the new schemas are: The user has its profile in the properties of the node. A money pool is another type of node. Thus the users can have edges between them with the label ‘friends’ and there can be relations between the users and the money pools with the label ‘participates_in’ or something similar.