I'm learning batch for the fun of it (so I can make quick and simple games), and it would be great if I could print at certain coordinates. How do I do this? Can I do this? Something like gotoxy(x,y) in C++.
Example:
___________________
| |
| |
| Print here |
| |
| |
|___________________|
Related
Assuming there is a gigantic organization with a crazy way to manage. Each employee has one or multiple managers, managers are employees themselves who have one or multiple managers on top.
employee table
| id | name |managers_id|
| -------- | -------------- |-----------|
| 1 | Smith | 5,6 |
| 2 | Matt | 1 |
| 3 | Bob | 1,2 |
| 4 | Adam | 1,3 |
| 5 | Suzi | 6 |
| 6 | Emily | 23,25 |
| ... | ... | ... |
It is a one-way management chain, no loops, meaning it goes A-B-C-D, A-a-b-C-D etc, no such case as A-B-C-D-A
The query is to get the management chains, say C has two management chains on top:
A-B-C
A-a-b-C
C also has one chain below:
C-D
The level of C along the chains is not a matter.
In theory, there is no limitation on the number of levels, the chain can keep going indefinitely.
I was thinking about 'inheritance' but probably it is not the solution.
Any tips on how to design this postgres dababase, please? Thank you.
Goal: Use SUMIFS to get the sum of value if color is Red or Yellow. Outcome should be 3.
+---+--------+-------+---+-----------+
| | A | B | C | D |
+---+--------+-------+---+-----------+
| 1 | Key | Value | | Condition |
| 2 | Red | 1 | | Red |
| 3 | Yellow | 2 | | Yellow |
| 4 | Green | 3 | | |
+---+--------+-------+---+-----------+
Problem:
It works if I hardcode the condition {"Red","Yellow"}. The result is 3.
=SUM(SUMIFS(B2:B4, A2:A4, {"Red","Yellow"}))
But if I reference the condition by cell D2:D3, I get 0.
=SUM(SUMIFS(B2:B4, A2:A4, D2:D3))
Question: How do I reference the condition dynamically by cell and make it work?
Use SUMPRODUCT() instead of SUM():
=SUMPRODUCT(SUMIFS(B2:B4,A2:A4,D2:D3))
One note:
This variation allows the expansion of the lists without the need to reapply the ranges:
=SUMPRODUCT(SUMIFS(B:B,A:A,D2:INDEX(D:D,MATCH("zzz",D:D))))
Alternatively, you can use SUMIF() together:
=SUMIF(A2:A4,"Red",B2:B4)+SUMIF(A2:A4,"Yellow",B2:B4)
Or make sure you're using CTRL+SHIFT+ENTER with your current formula attempt.
I am trying to design a model for our future database of our toys and certain measurements that have to be done post-production. I have trouble grasping how to model this. I have tried multiple ways, but none of them seem optimal and in the end I've always lost out on the connectivity between entities.
What I need to achieve is some kind of meaningful relationship between the following:
A toy (with some trivial properties).
A series of toys (multiple toys can be related to one series and a toy can only belong to one series).
Measurement steps. There are currently 6 of these steps. Each step has its own input parameters and these vary in type as well as in number (eg. only 3 parameters for measurement step 1 and 10 parameters for measurement step 2).
With each series, a sequence of these measurement steps is defined. Duplicates of tests are allowed (eg. measurement step 1 > measurement step 4 > measurement step 1 is a valid sequence). The sequence along with the parameters must be stored somewhere for future reference.
Each toy goes through the sequence of measurements that is defined by its series. All of the results must be stored somewhere (for each individual toy).
If I split the measurement steps into their own tables I can't reference them conditionally (as foreign keys) to some other table.
If I try to serialize part of the data I lose the ability to make connections between individual measurement steps, measurement results (at least with queries) etc.
I know people here generally hate/don't answer these kinds of "discussion-like" questions, but I'd ask of you to at least point out what is a good practice in a system where I need to store this locally on a machine, but need a database to hold the data - to move towards serial-like data and just do general relationships where it is easy to do so or keep trying to normalize it as much as possible?
If measurements steps share most of attributes (or are of the same type, like what you called PARAMETERS), and I understood correctly your definitions, I would make something like this.
It could be a starting point.
+----------------------------+ +------------------------------+
| TOYS | | TOY_SERIES |
+-----+----------------------+ +---------+--------------------+
| PK | ID_TOY | +----------+ PK, FK1 | ID_S +--------+
| | | | +------------------------------+ |
| FK1 | ID_S +---------+ | | ... | |
+----------------------------+ | | | |
| | ... | | | | |
| | | | | | |
+-----+----------------------+ +---------+--------------------+ |
|
|
|
|
+------------------------------+ |
| BR_SER_MEAS | |
+---------+--------------------+ |
| PK, FK1 | ID_S +--------+
| | |
| PK, FK2 | ID_M +--------+
| | | |
| PK | ID_SEQ | |
| | | |
+---------+--------------------+ |
|
|
+------------------------------+ |
| MEASURE_STEPS | |
+------------------------------+ |
| PK ID_M +--------+
+------------------------------+
| PARAM_01 |
| ... |
| PARAM_10 |
| |
| |
+------------------------------+
In Cucumber, we can directly validate the database table content in tabular format by mentioning the values in below format:
| Type | Code | Amount |
| A | HIGH | 27.72 |
| B | LOW | 9.28 |
| C | LOW | 4.43 |
Do we have something similar in Robot Framework. I need to run a query on the DB and the output looks like the above given table.
No, there is nothing built in to do exactly what you say. However, it's fairly straight-forward to write a keyword that takes a table of data and compares it to another table of data.
For example, you could write a keyword that takes the result of the query and then rows of information (though, the rows must all have exactly the same number of columns):
| | ${ResultOfQuery}= | <do the database query>
| | Database should contain | ${ResultOfQuery}
| | ... | #Type | Code | Amount
| | ... | A | HIGH | 27.72
| | ... | B | LOW | 9.28
| | ... | C | LOW | 4.43
Then it's just a matter of iterating over all of the arguments three at a time, and checking if the data has that value. It would look something like this:
**** Keywords ***
| Database should contain
| | [Arguments] | ${actual} | #{expected}
| | :FOR | ${type} | ${code} | ${amount} | IN | #{expected}
| | | <verify that the values are in ${actual}>
Even easier might be to write a python-based keyword, which makes it a bit easier to iterate over datasets.
I'm designing a card game (think Magic the Gathering for purposes of this example) and want to take the information for the cards and store it in a database. In this game, there are events (for instance, one card might say "when this comes into play, opponent takes 2 damage") that are tied to a particular card. The design decisions have led to loosely building the cards in a builder factory, but I'm looking to take the cards and store them in a database instead. Since most of the cards are instances of a base "Card" class, it's easy to load the features common to every card (name, cost, etc.) but I've struggled to find a good way to tie these events to a single type of card. The only way I have thought of so far was to store the function name in the database and use late binding to register the event when the card is loaded. Is there a better way to do this?
The only similar post I've found is this: Store function name in database and then execute it
The answer of using eval() seems similar to late binding, but got down-voted. However, no one had a better suggestion how to perform this function.
This sounds like a usable approach, however it is questionable if it is a good one.
Why don't you construct propper objects from a card representation in the database? Either by using an object database, or, more likely, but using object-relation-mapping. THis way you can represent each type of card in a clean and easy to read and use way yet work with rich instances of specialized classes derived from a common base class.
So you use a common table to store all the cards like this:
+-------------------------------------------------+
| card type | data1 | data2 | data3 | ... | dataN |
+-------------------------------------------------+
| Card | 123 | 456 | 789 | ... | abc |
| CardS1 | 123 | 456 | 789 | ... | abc |
| CardS3 | 123 | 456 | 789 | ... | abc |
| CardS2 | 123 | 456 | 789 | ... | abc |
...
And a class hierarchy like this:
+---------------------------+
| class Card |>-+
+---------------------------+ |
| var data1 | |
| var data2 | |
| var data3 | |
| ... | |
| var dataN | |
| baseMethod1() | |
| baseMethod2() | |
+---------------------------+ |
|
+---------------------------+ |
| class CardS1. public Card |<-+
+---------------------------+ |
| specialMethod_1_1() | |
+---------------------------+ |
|
+---------------------------+ |
| class CardS2. public Card |<-+
+---------------------------+ |
| specialMethod_2_1() | |
| specialMethod_2_2() | |
+---------------------------+ |
|
+---------------------------+ |
| class CardS3. public Card |<-+
+---------------------------+
| specialMethod_3_1() |
+---------------------------+