Reputation
526
Top tag
Next privilege 1,000 Rep.
See votes, expandable usercard
Badges
1 4 18
Newest
 Teacher
Impact
~24k people reached

19h
comment MVC Best practices (view acquiring data directly from model) and Yii Framework
Dear ugly downvoter. Have enough courage to express any problems in this answer, that caused you to downvote it?
Jul
17
awarded  Teacher
Jul
17
answered Mobile applications in Delphi
Jun
21
accepted Why should I use lookup tables at all?
Jun
21
comment Why should I use lookup tables at all?
I have tried to read your answer five times and still didn't catch your point. No, I'm not mixing all these things. I'm simply asking, why should I store my lookup / dictionary data in database, instead of keeping it in a file. I'm suggesting, that keeping this kind of static data in file is much faster then reading it from database and would like to know, if I'm not mistaken? That's all.
Jun
21
asked Why should I use lookup tables at all?
Jun
21
accepted At which point using string-based enums can become a real problem?
Jun
21
comment At which point using string-based enums can become a real problem?
I, of course, made a pure mistake and false base assumption, due to my lack on knowledge. Therefore, I'm totally and completely grateful to all of you for all the fixes, that made this question "valid". Free edits is one of the most fabulous feature of SE. Thank you!
Jun
20
asked At which point using string-based enums can become a real problem?
Jun
11
comment How to acquire data and render page in context of REST/API application?
I HAVE a REST API. My mobile apps are using it. Now, I'm building a website (name it frontend, if you wish). I'm asking, if frontend (written in the same language, PHP, and run on the same server as API) should access data directly (models / PDO / MySQL) or if it also should be a client, that is accessing data only through API calls?
Jun
11
asked How to acquire data and render page in context of REST/API application?
May
29
comment How to store data that is recorded with different frequency?
Well... quite an interesting point of view on the matter, that I never thought about. I don't know, if I'm going to push this the way you suggest, but the idea of storing only stats info (min, max, avg etc.) instead of real values for 1/10th values really need further examination. I'm accepting your answer as very interesting one. However, I might unaccept it, if something better ever arrives.
May
29
accepted How to store data that is recorded with different frequency?
May
28
comment How to store data that is recorded with different frequency?
@MarekGrzenkowicz That's an interesting idea to evaluate. I must admit, that I haven't thought about such solution. Thanks!
May
27
awarded  Nice Question
May
24
accepted How should an API or server respond when a device connects with a different account than it is bound to?
May
22
comment How to store data that is recorded with different frequency?
@Euphoric I'm completely fine with post-processing of data retrieved from database before it is actually rendered as a graph. This is even necessary in this case, as data will be provided by API means and rendered into graph by an end-point client, after whatever post-processing it needs.
May
22
revised How to store data that is recorded with different frequency?
added 1522 characters in body
May
22
revised How should an API or server respond when a device connects with a different account than it is bound to?
added 380 characters in body
May
22
comment How should an API or server respond when a device connects with a different account than it is bound to?
I do use pre-existing hardware identification to identify devices, so second scenario occurs. However, please note, that we're talking about non-computer devices. Dropbox is just an example. I'm talking about scenario, where 95% of devices is always used by one and the same user and are not shared among others. And described situation could (per assumption) only occurs as an result of error or intentional, but non-standard actions (hacking, checking what will happen, if, etc.).