-
Notifications
You must be signed in to change notification settings - Fork 0
/
Copy pathTODO.txt
87 lines (78 loc) · 7.37 KB
/
TODO.txt
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
Technical / architecture TODO:
- Add checkstyle plugin / eclipse settings for lots of stuff including javadoc
X Set JAVA_HOME back to Java 8 after Scala Coursera is done
- Generic PYH Spring Boot server class with properties file finding stuff etc.
- Rename all packages in api? -> hm, no, then impl should be there as well, not nice. or api as subpackge of module?
- Release branch in Github: merge from master for every release + tags with number. HEAD of release branch is latest 'production' version
- Split the DB usage into several datasources/entitymanagers/transactionmanager, see: http://docs.spring.io/spring-boot/docs/current/reference/htmlsingle/#howto-two-datasources
- Property files only need to be imported once, and it can be any (Spring) class. Plus Spring boot config can be in there as well!
- Check usage of synchronized, same thread can (of course) still enter synchronized methods of the same class! (particularly with looping and adding/removing)
- Naming convention for PYH domain classes: PyhSomething, to avoid conflicts with other API's like Philips and own config JAXB classes
- Document all various comments in some kind of format (Github Flavored MD?)
- Document configuration decisions: properties file for technical stuff (connection info, account info, datasources, etc.)
- PYH Utils: extract the common module functionality
- Use PyhApi on all api projects and let clanup stuff do it's work (also delete old fix serialization scope config)
- Split static and dynamic data for all PYH modules, so introduce LightState, DeviceState etc and split the API calls for this information. (see shopping for example)
- Add dependencies on specific general API's only at bootstrap level, they should only be needed at runtime
- Hibernate for JPA
- Moneta for Money API?
- Spring for @Inject?
- Database driver for JDBC
- Persistence (sensor data in DB), current config as memory dump or so, should be restorable after midnight reboot.
- Use @Service instead of Bean for all service implementing classes in all modules (like ShoppingImpl, PhilipsHueImpl, etc)
- Refactor Mock maven module to use commons-pyh and it's version of the generated mixin.
- Add geografical data to items (floor, room, location in room, size)
- Introduce Maven plugin that will fail the build if there are multiple versions on the classpath of the same dependency - to try to avoid classpath conflict issues
- Property keys as static final String declarations instead of hardcoded inline
- UTF-8 property is inherited from parent right? So no need to repeat it in all child projects everywhere.
- Put git ignore of common stuff (.project, .classpath, .settings, target) at a higher level, so they are not needed per project
- Config XSD/XML files: why in separate module for server, but not for modules themselves? -> accept or move server config inside server module
- XSD/XML at server level for 'filling' the server with content en behaviour (activities, rules, etc)
- XSD/XML per module with non-technical, or at least more subject related stuff, like devices for IR, etc.
- Only allow same server deployment of backend and frontend for security reasons? Or proper config for CORS in xml/props
- Internally in modules: use mapping from id to model impl value object to easily do existence checks and retrieve data
- Workaround for using qualifier on injected beans of type Executor? (result of using Spring Boot websockets with SockJS)
- Consider moving to a relational database for storing the static data, instead of XML. (dynamic data should be put into a database anyway)
- Don't rely on PyhImpl to provide equals on all fields, but use the same or similar methods externally in the pollers (should be done for shopping anyway)
- 'Cut off' any implementation details of the api implementing module by some sort of 'serializing' into a plain flat interface
implementing class when returning from an API call. Maybe with some AOP style (annotation) on api calls from within the server.
And for the simple implementing classes wasn't there a library with this (bytecode generating) feature that was often overlooked? Was is Jackson?
--> Yes it is: Mr. Bean: http://www.cowtowncoder.com/blog/archives/2011/08/entry_459.html
Actually, we might want something else or just the core of mr bean, since we don't want the whole JSON context here.
See AbstractTypeMaterializer: /~https://github.com/FasterXML/jackson-module-mrbean/blob/master/src/main/java/com/fasterxml/jackson/module/mrbean/AbstractTypeMaterializer.java
- After implementing this for all stuff returned by API's, you could probably get rid of the dynamic mixin stuff, since there
won't be any 'noise' anymore in the objects that will be serialized. (but probably better to keep it anyway, since that could always change in the
future and the mixin stuff whould be needed again. it doesn't break the mr. bean stuff anyway, so safe to keep it around as well)
- Move to a more standard form of authentication, like OAuth2 Resource Owner Password Flow. Compatible with Spring Security: http://projects.spring.io/spring-security-oauth/docs/oauth2.html
- POM file management
- right scopes for obvious dependencies in parent pom: e.g. test for junit (hmm, or not, not really clear on child project what the scope is)
- bom dependencies in parent, e.g. Spring
- Naming scheme:
- Think about and make consistent: the xsd namespaces for main config and module configs
-> name 'clash' for tags infraRed / infraRedConfig in main/server and infrared spcific config files
- When to use camel case, when dashes '-'?
- Fully create, test and use vagrant config for PYH server. See boot.sh and provisioning.sh for details and TODO's.
- Default lightning conditions - schedule (different from normal scheduling mechanism)
// Is setting a certain lighting condition considered an activity? Or maybe there should be some sort of default behavior
// with some options, that is considered the default for that day for instance. Just like a thermostate actually.
//EG: when at home: do this, when not:do this
// and do this could be either time based or 'darkness based' or combo setting scenes
// you could even expand that to e.g. auto-starting the news every (work)day at 8 :) -> scheduled activity activation
// Hmm, more generically this sounds like a scheduling feature, which is of course something that should be added.
// But maybe specifically for the lighting it makes sense to have a default. e.g.:
// - when dark -> turn light on at mood level depending on the current time, between energy (16:00) and relax (20:00)
// From 20:00 onward (max), stay at relax, but slowly decrease brightness till 24:00 (lowest brightness)
// Turning off completely still will be a manual action.
Module names and abbreviations:
Sync usage of these over the whole of PYH:
Full name in documentation (Javadoc etc), ...
Module id in maven module names, XML config tags, properties files, ...
Abbreviation in package names, ...
Full name - module id - abbreviation
Server - server - server
Philips Hue - philips-hue - hue
Infrared - infra-red - ir
Eneco Toon - eneco-toon - toon
Spotify Music - spotify-music - spotify
Sound Interaction - sound-interaction - sound
Possible future modules: Netflix, Uitzending Gemist, Shopping list / 'voorraadbeheer' / ...