CollPoll is mobile-first, AI-powered SaaS platform for digital transformation of key academic as well as administrative activities

CollPoll

1811 Dictionary in the Vulgar Tongue, by Francis Grose is part of HackerNoon’s Book Blog Post series. You can jump to any chapter in this book here: [ ]. Section O LINK TO TABLE OF LINK Section O O BE JOYFUL. I'll make you sing O be joyful on the other side of your mouth; a threat, implying the party threatened will be made to cry. To sing O be easy; to appear contented when one has cause to complain, and dare not. OAF. A silly fellow. OAFISH. Simple. OAK. A rich maa, a man of good substance and credit. To sport oak; to shut the outward door of a student's room at college. An oaken towel; an oaken cudgel. To rub a man down with an oaken towel; to beat him. OATS. He has sowed his wild oats; he is staid, or sober, having left off his wild tricks. OATHS. The favourite oaths of the thieves of the present day are, "God strike me blind!" "I wish my bloody eyes may drop out if it is not true!" "So help me God!" "Bloody end to me!" OAR. To put in one's oar; to intermeddle, or give an opinion unasked: as, To be sure, you must put in your oar! OBSTROPULOUS. Vulgar misnomer of OBSTREPEROUS: as, I was going my rounds, and found this here gemman very obstropulous, whereof I comprehended him as an auspicious parson. OCCUPY. To occupy a woman; to have carnal knowledge of her. ODDFELLOWS. A convivial society; the introduction to the most noble grand, arrayed in royal robes, is well worth seeing at the price of becoming a member. ODDS PLUT AND HER NAILS. A Welch oath, frequently mentioned in a jocular manner by persons, it is hoped, ignorant of its meaning; which is, By God's blood, and the nails with which he was nailed to the cross. ODD-COME-SHORTLYS. I'll do it one of these odd-come-shortly's; I will do it some time or another. OFFICE. To give the office; to give information, or make signs to the officers to take a thief. OGLES. Eyes. Rum ogles; fine eyes. OIL OF BARLEY, or BARLEY BROTH. Strong beer. OIL OF GLADNESS. I will anoint you with the oil of gladness; ironically spoken for, I will beat you. OIL OF STIRRUP. A dose the cobler gives his wife whenever she is obstropulous. OI POAAOI (Proofreaders Note: Greek Letters). (CAMBRIDGE.) The many; the multitude; who take degrees without being entitled for an honor. All that is REQUIRED, are three books of Euclid, and as far as Quadratic Equation's in Algebra. See PLUCKED. OLD. Ugly. CANT. OLD DOG AT IT. Expert, accustomed. OLD HAND. Knowing or expert in any business. OLD HARRY. A composition used by vintners to adulterate their wines; also the nick-name for the devil. OLD DING. See OLD HAT. OLD MR. GORY. A piece of gold. OLD NICK. The Devil: from NEKEN, the evil spirit of the north. OLD ONE. The Devil. Likewise an expression of quizzical familiarity, as "how d'ye do, OLD ONE?" OLD PEGG. Poor Yorkshire cheese, made of skimmed milk. OLD POGER. The Devil. OLD STAGER. One accustomed to business, one who knows mankind. OLD TOAST. A brisk old fellow. CANT. OLD DOSS. Bridewell. OLIVER'S SCULL. A chamber pot. OLLI COMPOLLI. The name of one of the principal rogues of the canting crew. CANT. OMNIUM GATHERUM. The whole together: jocular imitation of law Latin. ONE IN TEN. A parson: an allusion to his tithes. ONE OF US, or ONE OF MY COUSINS. A woman of the town, a harlot. ONION. A seal. Onion hunters, a class of young thieves who are on the look out for gentlemen who wear their seals suspended on a ribbon, which they cut, and thus secure the seals or other trinkets suspended to the watch. OPEN ARSE. A medlar. See MEDLAR. OPTIME. The senior and junior optimes are the second and last classes of Cambridge honors conferred on taking a degree. That of wranglers is the first. The last junior optime is called the Wooden Spoon. ORGAN. A pipe. Will you cock your organ? will you smoke your pipe? ORTHODOXY AND HETERODOXY. Somebody explained these terms by saying, the first was a man who had a doxy of his own, the second a person who made use of the doxy of another man. OSCHIVES. Bone-handled knives. CANT. OSTLER. Oatstealer. OTTOMY. The vulgar word for a skeleton. OTTOMISED. To be ottomised; to be dissected. You'll be scragged, ottomised, and grin in a glass case: you'll be hanged, anatomised, and your skeleton kept in a glass case at Surgeons' Hall. OVEN. A great mouth; the old woman would never have looked for her daughter in the oven, had she not been there herself. OVERSEER. A man standing in the pillory, is, from his elevated situation, said to be made an overseer. OUT AT HEELS, OR OUT AT ELBOWS. In declining circumstances. OUTRUN THE CONSTABLE. A man who has lived above his means, or income, is said to have outrun the constable. OUTS. A gentleman of three outs. See GENTLEMAN. OWL. To catch the; a trick practised upon ignorant country boobies, who are decoyed into a barn under pretence of catching an owl, where, after divers preliminaries, the joke ends in their having a pail of water poured upon their heads. OWL IN AN IVY BUSH. He looks like an owl in an ivy bush; frequently said of a person with a large frizzled wig, or a woman whose hair is dressed a-la-blowze. OWLERS. Those who smuggle wool over to France. OX HOUSE. He must go through the ox house to bed; a saying of an old fellow who marries a young girl. OYES. Corruption of oyez, proclaimed by the crier of all courts of justice. OYSTER. A gob of thick phlegm, spit by a consumptive man; in law Latin, UNUM VIRIDUM GOBBUM P'S. To mind one's P's and Q's; to be attentive to the main chance. P.P.C. An inscription on the visiting cards of our modern fine gentleman, signifying that they have called POUR PRENDRE CONGE, i.e. 'to take leave,' This has of late been ridiculed by cards inscribed D.I.O. i.e. 'Damme, I'm off.' About HackerNoon Book Series: We bring you the most important technical, scientific, and insightful public domain books. This book is part of the public domain. Urbana, Illinois: Project Gutenberg. Retrieved April 2022 from Grose, Francis. 2004. 1881 Dictionary in the Vulgar Tongue. https://www.gutenberg.org/cache/epub/5402/pg5402.html This eBook is for the use of anyone anywhere at no cost and with almost no restrictions whatsoever. You may copy it, give it away or re-use it under the terms of the Project Gutenberg License included with this eBook or online at , located at . www.gutenberg.org https://www.gutenberg.org/policy/license.html

1811 Dictionary in the Vulgar Tongue: Section O

Crypto Crash? Not Really... 

The Importance of Replication Databases are one of the pillars of any application. If a database server goes down, the whole system will no longer perform its basic services: authenticate users, publish our beloved Hackernoon posts, store comments for the crush’s selfies… This is why designing the system for (the ability of a distributed system to operate continuously without failing for a designated period of time) is essential. High Availability One solution to achieve High availability is to have more components than needed. So for our database system, we can replicate the master database, and if it fails, switch it out for one of the working replicas. Introducing The Solution First, we have to list out our constraints: clients should connect to the database directly and have no interaction with our replication system. our whole system should be very fast and resource-efficient How do we know what part of the database tables has been inserted, deleted, or modified? TRIGGERS! THEY ARE AWESOME !! Database triggers allow us to execute SQL functions whenever an event is received. An event can be any operation such as INSERT, UPDATE, DELETE or TRUNCATE. Triggers are useful for a wide range of cases, like verifying constraints or boosting performance. In our case, we will use triggers to notify our Python listener when data has been removed or added. We define a procedure called that will handle sending notifications about the changes in the database. This is how to define the trigger on the table "users": notify_account_changes() CREATE TRIGGER users_changed
    AFTER INSERT OR UPDATE
    ON users
    FOR EACH ROW
EXECUTE PROCEDURE notify_account_changes(); Okay, now on to the next problem. How the heck can we now notify programs outside our server about these changes? from the PostgreSQL documentation ( ): https://www.postgresql.org/docs/current/sql-notify.html The command sends a notification event together with an optional “payload” string to each client application that has previously executed for the specified channel name in the current database. NOTIFY LISTEN channel In other words, we can have many listeners on a channel by executing . And to send notifications, we use the command or the built-in system function . The payload is a message that we want to send. In our case, the notification payload will include: LISTEN channel_name NOTIFY pg_notify('channel_name', 'payload') TG_TABLE_NAME: name of the table that launched the trigger. TG_OP: the operation that launched the trigger (INSERT, DELETE…). NEW: which is a variable given by the TRIGGER so that we know what the new inserted or updated data. OLD: which is also a variable given by the TRIGGER so that we know the old values before updating or deleting the record. Here’s the code for the notify_account_changes() CREATE OR REPLACE FUNCTION notify_account_changes()
    RETURNS trigger AS
$$
BEGIN
    PERFORM pg_notify(
            'users_changed',
            json_build_object(
                    'table', TG_TABLE_NAME,
                    'operation', TG_OP,
                    'new_record', row_to_json(NEW),
                    'old_record', row_to_json(OLD)
                )::text
        );

    RETURN NEW;
END;
$$ LANGUAGE plpgsql; Now we've received a notification about changes from the triggers. At this stage, we have completed the database side. Listening to the Notifications from Python to connect to the PostgreSQL we are going to use the one and only “psycopg2” library. we can install it using: pip install psycopg2 To connect to the PostgreSQL database and start listening: conn = psycopg2.connect(host="localhost", dbname="DBNAME", user="USERNAME", password="PASSWORD")
conn.set_isolation_level(psycopg2.extensions.ISOLATION_LEVEL_AUTOCOMMIT)
cursor = conn.cursor()
cursor.execute("LISTEN users_changed;") enables us to execute SQL commands like SELECT or INSERT… cursor.execute() Now that we are listening to notifications. How can we parse them? def handle_notify():
    conn.poll()
    for notify in conn.notifies:
        print(notify.payload)
    conn.notifies.clear()

loop = uvloop.new_event_loop()
asyncio.set_event_loop(loop)
loop.add_reader(conn, handle_notify)
loop.run_forever() Here we used asynchronous libraries, and . The line enables us to invoke the function only when the file descriptor (which represents the connection to our database) has an incoming stream of data. After executing uvloop asyncio loop.add_reader(conn, handle_notify) handle_notify() conn INSERT INTO users VALUES (2,'al'); The output is: {
"table" : "users",
"operation" : "INSERT",
"new_record" : {
   "id":2, 
   "name":"al"
    },
"old_record" : null
} Now that we have received all the information we need about database changes. How can we replicate it? Before we do this, we have to address some problems: PostgreSQL NOTIFY queues are not persistent. If we are not listening, notifications will be lost. Having many listeners’ connections can make the database server slower. Introducing RabbitMQ to solve these problems we introduce . RabbitMQ RabbitMQ is a . It gives your applications a common platform to send and receive messages, and your messages a safe place to live until received. messaging broker - an intermediary for messaging RabbitMQ allows us to send messages using queues to different parts of our distributed system. It uses persistent queues to save messages and transactions to ensure that they have been executed properly. So how does RabbitMQ work? Each python script will have its own queue. to send messages to all queues we will send it to a fanout exchange with the script.  the fanout exchange broadcasts every message to all connected queues. changes_listener changes_publisher To use RabbitMQ with python we will use the library pika pip install pika In we will connect to the RabbitMQ server. Then we will create an exchange named “replication”. For each notification received we will broadcast it to all RabbitMQ queues. changes_publisher.py connection = pika.BlockingConnection(pika.ConnectionParameters(host='localhost'))
channel = connection.channel()
channel.exchange_declare(exchange='replication', exchange_type='fanout')

def handle_notify():
    conn.poll()
    for notify in conn.notifies:
        channel.basic_publish(exchange='replication', routing_key='', body=notify.payload)
    conn.notifies.clear() And in our changes_listener.py connection = pika.BlockingConnection(pika.ConnectionParameters(host='localhost'))
channel = connection.channel()
channel.exchange_declare(exchange='replication', exchange_type='fanout')
result = channel.queue_declare(queue='', exclusive=True)
queue_name = result.method.queue
channel.queue_bind(exchange='replication', queue=queue_name)


def callback(channel, method, properties, body):
    op = json.loads(body.decode('utf-8'))
    print(op)


channel.basic_consume(queue=queue_name, on_message_callback=callback, auto_ack=True)
channel.start_consuming() Here we connect to RabbitMQ, declare fanout exchange “replication”, declare temporary queue, bind the queue to the exchange and start consuming messages. on each new message received our callback function will be executed. Executing this SQL query will result in this output from the : UPDATE users SET name='alfonso' WHERE id=2; changes_listener.py {
  'table': 'users',
  'operation': 'UPDATE',
  'new_record': {
    'id': 2,
    'name': 'alfonso'
  },   
  'old_record': {
    'id': 2,
    'name': 'al'
  }
} Writing the changes to the replicas Now that we have received the changes in our python script, all that is left to do is commit these changes. To do this, we will have to change our callback function to generate SQL commands from every received JSON message: def operation_handler(op):
    def handle_insert():
        table, data = op['table'], op['new_record']
        sql = f"""INSERT INTO {table} 
        VALUES ('{data['id']}','{data['name']}');
        """
        return sql
    sql = None
    if op['operation'] == 'INSERT':
        sql = handle_insert()
    # we can add other operation handlers here
    return sql


def callback(channel, method, properties, body):
    op = json.loads(body.decode('utf-8'))
    sql = operation_handler(op)
    cursor.execute(sql) In the callback, when we receive the message, we convert it to a dictionary and pass it to . This function will look at the message and return the appropriate SQL using its values. operation_handler(op) THIS IS IT. WE NOW HAVE ALL THE PIECES WORKING. If we check the replica database after executing a simple SQL query We find this: INSERT INTO users VALUES (2,'al'); PS: PostgreSQL has built-in options for database replication, but our solution enables us to have full control over the replication process. We can replicate only certain tables, certain users or modify the records in any way we want. Final Notes Step by step, we have finished implementing our database replication system. We have gone from configuring triggers and notifications in the database to broadcasting the changes using RabbitMQ to finally writing the changes back into a PostgreSQL replica. Implementing this solution was not easy, it required a lot of pieces, but it is all worth it. Offering users zero downtime is a huge business advantage. Here’s the code for the project https://github.com/Bechir-Brahem/postgres-database-replicator Thank you for reading <3

Replicate PostgreSQL Databases Using async Python and RabbitMQ for High Availability

As you may know, a distributed ledger platform is a type of software that enables multiple parties to maintain a shared, decentralized database in a secure and transparent way. One key thing those parties need is consensus. They must agree about the state of the ledger and its data. That’s why we have miners (in PoW blockchains), validators / forgers/ bakers/ etc. (in PoS blockchains), and Order Providers (in a DAG). Proof-of-Work (PoW) blockchains, such as Bitcoin, solved the consensus problem with mining. In this case, “special” users are in charge of mining (producing) new blocks of transactions. They do so by using their computer power and following strict cryptographic rules. The more computer power they have, the more blocks they can mine, and the more coins they’ll receive for it. On Proof-of-Stake (PoS) blockchains, miners are replaced by validators (a misleading name since what they do is much more than just checking the validity of transactions). Instead of using their computing power, validators buy the right to produce blocks. They have to either lock away a certain number of coins in a special crypto address, or just own them, or have them delegated by others, so they can create blocks and obtain transaction fees in return. The more coins they buy, lock, or are delegated with, the more rights and benefits they have. The system is more decentralized in a Directed Acyclic Graph (DAG) distributed ledger, like Obyte. There’s no need for computing power or buying coins. Instead, it is users who build the ledger. Order in a DAG A DAG system operates differently from a blockchain system. It doesn’t have blocks, but just transactions, directly connected to each other. The graph is constructed only by users with each transaction they add. The new transactions link to the previous ones, creating a directed acyclic graph (DAG). They’re recorded without the assistance of miners or block producers. To prevent double-spending (spending the same coins twice or more), the order of transactions is critical. A DAG provides partial ordering through parent-child relationships, but full ordering is established through "Order Providers." These providers, who are typically well-respected individuals or companies, create transactions like everyone else and these transactions serve as waypoints for ordering all other transactions. In other words, their transactions are like guides or small headlights for the rest of operations to follow a single path. In return, they get a portion of the transaction fees, but that shouldn’t be the main purpose of an Order Provider. They should be respectable members of the community, with great interest in its well-being. And they can’t do a lot of things that miners and validators can. What miners and validators can do? Anyone with the proper hardware, energy, or monetary resources could be a miner or a validator in a blockchain. It could lead to centralization, where only a few powerful parties control the entire network. That’s not necessarily a good thing, since the more resources they have, the more power they get. Blockchains aren’t supposed to be modified or censored in any way, but they could be if those powerful parties join forces, or are coerced to do something together by someone even more powerful, such as a government. A 51% attack in PoW networks is a great example. In theory, Double-spending, temporarily freezing the network, censorship of users, all of it would be possible. They wouldn’t be able to directly steal funds from personal wallets, but they could censor any address, slow transactions, and increase the fees. if 51% of the miners collude, they could change the blockchain in their favor. Threats for PoS The 51% attack is much less probable in PoS networks. Or, at least, it doesn’t have the same name because there’s no computing power involved. But other attacks are possible. Ethereum, the most prominent PoS network so far, published a document about it. According to , a validator would need at least 33% of the total stake (locked coins) to succeed in several types of attacks. its website . Reset the network, double-spend, censor transactions, discriminate valid blocks, etc. And the only defense is the cost that would take. Besides, with over 66% of the total stake, they’d be able to do almost anything “By purchasing additional ether to control 66% rather than 51%, the attacker is effectively buying the ability to do ex post reorgs and finality reversions (i.e. change the past as well as control the future). The only real defenses here are the enormous cost of 66% of the total staked ether, and the option to fall back to the social layer to coordinate adoption of an alternative fork.” Some more bad news here? Allegedly, 64% of the total staked ETH is by only 5 entities. And 50% of the Bitcoin hashrate is by two mining pools. There is a centralization problem there. However, acquiring so much computing power or total stake just to attack these networks would be absurdly expensive and counterproductive for the attacker (not the same story for small-market-cap altcoins, though). controlled controlled MEV and censorship For now, most 51%/33%/66% attacks are just theoretical for the stronger cryptocurrencies. But there are some other ways that these intermediaries (miners and validators) can harm the average users. One of them is the Miner Extractable Value (MEV) of every block. Like everyone else in this world, block producers are constantly looking to maximize their profits. MEV is one of those ways. It refers to the value that can be extracted from a given set of transactions in a blockchain network, beyond the transaction fees. or insert their own before the user’s, even at the expense of others. Block producers can cherry-pick which transaction to approve first to increase their gains, This kind of activity could lead to increased transaction costs and reduced trust in the network. It could even lead to rewriting of the blockchain. As Binance : described it “On a fundamental level, if the value from reordering transactions in a previous block is greater than the rewards and fees of the next block, MEV could make it economically rational for a block producer to commit to blockchain reorganization. This would then threaten the consensus and integrity of the network.” Censorship is another realistic possibility —some Bitcoin mining companies They can filter transactions (not validate them) if the origin doesn’t meet their requirements, like Know-Your-Customer (KYC) measures. This could restrict the rights of the end-user, and effectively prevent them from transacting. have already tried it. And they are free to impose any requirements they like, while the governments are free to impose any requirements they like on the block producers. The worst part about censorship is that it can be applied selectively to a small minority of users while the network continues to operate normally for everybody else. This way, it can take hold without any significant pushback (other than verbal) and creepingly spread further without much resistance either. What Order Providers can do? The rewards to act maliciously in a DAG aren’t a lot, while the price could be higher. Order Providers can collude, as much as miners and validators. But they have fewer reasons to do so, in the first place. Being companies, organizations, and reputable users, they could lose their reputation and/or businesses if they misbehave. Anyway, if we imagine a scenario where they do misbehave and collude, they can’t earn much from it. It’s not possible to rewrite the DAG history and insert a double-spend (spend the same money several times). It’s also impossible to steal funds from users since they don’t have access to private keys. They can’t apply selective censorship either, or discriminate against transactions. For that, they’d need to . censor ALL transactions, starting from the single transaction they want to censor Basically, the only thing they can do is stop the network, until a new network with a new set of Order Providers is restarted from the point where the old network stopped. They were selected by the community itself to begin with, so, the same community can take the role away. No one can buy their right to control a decentralized DAG. Order Providers in Obyte Obyte counts with twelve Order Provider addresses (previously known as Witnesses). Five of them are still controlled by the founder (Tony Churyumoff), in the absence of adequate candidates. They were mostly selected by community voting through their wallets, using the Poll chatbot. They also expressed their interest to be OPs in previous years, while complying with the : The other seven are controlled by independent parties. requirements Not anonymous: have a publicly known real name. To be well-known and trusted in the community. Having a lot to lose (material and/or nonmaterial) in case of misbehavior. The loss is the business (outside Obyte) and/or reputation. Offer enough technical expertise to ensure uninterrupted operation 24/7 and security of their private keys (they must not be stolen and used to post on their behalf). Adapt their own OP list when the community wants to change it in some way and the new candidate satisfies the above rules. That includes removing themselves from the list. After being accepted by the community, every OP installs a code that periodically posts from a constant address. Currently, we can consult them from our wallets, by just going to the section “Settings (Global Preferences) > Trusted Nodes.” Everything is transparent there: they appear with their Obyte address, real name, and links to more information. Five + Seven The five addresses of the founder that serve as OPs also work as Bitcoin oracle, Flight Delays Oracle, Real Name Attestor, Sports Oracle, and Price Oracle. Aside from them, we can find seven entities and individuals here. They’re the (an IoT community hub), the Dutch entrepreneur , the charity platform (run by Casper Niebe), the design studio , (co-founder of Busy.org and SteemConnect), the Chinese community , and the Institute for the Future at the . Bosch Connectory Stuttgart Rogier Eijkelhof PolloPollo Bind Creative Fabien Marino CryptoShare Studio University of Nicosia and the community accepts them by voting. The more headlights on our way to a decentralized future, the better. Anyone can join the OPs if they meet the requirements

Miners and Validators vs Order Providers in Crypto — What They Can Do If They Collude

Los proveedores de pedidos en criptomonedas no tienen muchos incentivos para confabularse entre sí: este es el motivo

Les fournisseurs de commandes en crypto n'ont pas beaucoup d'incitation à s'entendre - voici pourquoi

क्रिप्टो में ऑर्डर प्रोवाइडर्स के पास एक-दूसरे के साथ मिलीभगत करने के लिए ज्यादा प्रोत्साहन नहीं है - यहाँ पर क्यों

暗号の注文プロバイダーは、互いに共謀するインセンティブがあまりありません—これが理由です

Os provedores de pedidos em criptografia não têm muito incentivo para conspirar uns com os outros - eis o porquê

Các nhà cung cấp đơn đặt hàng trong tiền điện tử không có nhiều động lực để thông đồng với nhau - Đây là lý do tại sao

加密货币中的订单提供者没有太多相互勾结的动机——这就是原因

we covered setting up a basic Django project. By now you should have a directory that looks like this: In our last tutorial 0to100├── CHANGELOG.rst├── .gitignore├── .git│   └── HEAD│   ...├── README.rst├── docs├── requirements│   └── base.txt├── setup.py└── tutorial├── manage.py└── tutorial├── __init__.py├── settings.py├── urls.py└── wsgi.py 4 directories, 9 files Starting your app goes over creating your first app pretty well, but they skip out on a few important concepts. Instead of explaining everything along the way the tutorial, a lot is skipped for the purposes of being concise and quick. Before we start building an app, what exactly is an app? The Django Project’s tutorial Understanding what an App is. The first thing to understand is what exactly an app is. Unlike most MVC (or MTV) frameworks, Django forces you to break your code into separate “apps.” These apps should be totally self-contained, reusable, and plug-able. This is incredibly helpful because it means you can share functionality across multiple projects. For instance suppose you have a blog app and a photo gallery app. Now a common piece of functionality you might want to add to both of those is the ability to add “tags” to photos and blog posts. Now you could write that functionality into both apps and end up having a bunch of duplicate code that does the exact same thing. Django’s preferred method is to add a new app called “tags.” This app would contain all of the data and logic concerned with adding, removing, and editing tags from other apps. This ability to be self contained also means you can share your code with others and they can also use it. For instance if you didn’t want to write your own tagging library you could just run and now you have a self contained tagging library that someone else wrote. Because of the way taggit was written it can be use with any other apps. pip install taggit How do you decide what should be an app? This is probably the single biggest question new Django developers face. How do you know when certain functionality should be split up. Due to the nature of programming there isn’t a hard rule on this. The idea I ususally follow is: “If you can’t explain what your app does in one sentence, it should be more than one app” and so far that has served me pretty well. How startapp works So enough prose and theory, let’s actually write some code! To start an app in Django, make sure you are in the first “tutorial” folder. I will refer to this as your ‘django project folder’ from here on (the one with ). This folder will be where all of your apps live. Now run: manage.py $ python manage.py startapp polls$ ls Now as you can see we now have new folder called . While it may seem like startapp does some kind of magical thing to create this app, it actually doesn’t. All that happens is a folder is created with the name provided (i.e. polls), a few files are copied in, and one config file is added (apps.py). In fact you could create your own app in the terminal or in your file explorer just by creating 1 folder and 2 files. All that is required for an app folder is the folder, an , and an . polls __init__.py apps.py What gets created? So what does actually create? Let’s take a look and breakdown every file: startapp $ tree pollspolls├── admin.py├── apps.py├── __init__.py├── migrations│   └── __init__.py├── models.py├── tests.py└── views.py First there is the file. This file is where you generally put all of your configuration regarding Djangos builtin admin. admin.py Next is this file is used in Djangos internal app registery and is mainly used to store meta data. For the most part you won’t be modifying this much. apps.py, Then we have the file. This file is actually Pythons convention for determining modules. When you try to run or Python will search all folders in the Python Path. If a folder has an __init__.py file, Python will also search inside of that folder, otherwise it is ignored. So if we want to be able to import code from our app we need __init__.py. __init__.py import library from library import x polls Now we have the folder. Migrations are how Django builds your database. We will get into this later, but you will see “migrations” added to this folder as we start working with models. migrations Then we have the this file is where you should store all of your models related to this app. Models are how Django understands your database and how you want data stored. models.py Next we have . Sometimes you will see this as a folder instead. This file/folder is for adding unit and integration tests. This is something we will cover in much greater detail later on, but basically a test is code you write to make sure your code is running how you expected. tests.py tests Finally we have . This is the file where all of our business logic is stored. We will define all of our views related to this app, both Class-Based and Function, in this file. In other frameworks, you would probably call Djangos views “Controllers”. views.py Wait, that’s not all is it? If you’ve worked with Django or other MVC frameworks before you may notice something is missing. There isn’t anywhere to store static files or templates (views in other frameworks). By default doesn’t create these, but you can by running: startapp $ mkdir static templates$ lsadmin.py  apps.py  __init__.py  migrations  models.py  static  templates  tests.py  views.py That works perfectly fine and now Django will automatically start looking for static files in and looking for templates in . polls/static polls/templates You can also add more files just for the sake of organization too! I’ll review a few other files that are relatively common: — Used to store app specific mappings of URLs to views urls.py — Commonly used to store Djangos forms library subclasses forms.py — Commonly used to store “ ” in Django. signals.py signals Commonly used by third party libraries line Django Rest Framework and TastyPie to store api information. api.py — — Used to store Queryset managers managers.py Additionally a lot of third-apps use separate files similar to to store configuration on a per app basis. api.py Registering your App So now you’ve created an app, you know what everything does, but Django still does not know about your app! To make Django aware of your app you need to edit the file. Once you have it open search for , you should see a section that looks like this: tutorial/settings.py INSTALLED_APPS INSTALLED_APPS = ['django.contrib.admin','django.contrib.auth','django.contrib.contenttypes','django.contrib.sessions','django.contrib.messages','django.contrib.staticfiles',] This is a list of all of the apps that Django will use when you start up. To make Django aware of your amazing new polls app, just add to the end of the list: 'polls', INSTALLED_APPS = ['django.contrib.admin','django.contrib.auth','django.contrib.contenttypes','django.contrib.sessions','django.contrib.messages','django.contrib.staticfiles','polls',] That’s it. You have officially created a brand new app and made it compatible with Django! It doesn’t do a whole lot yet, but we will start to fix that in the next tutorial.

COLLPOLL

collpoll.com

-- employees

Since n.d.

COMPANY RANKING

COLLPOLL

EVERGREEN INDEX #3391

Representing this company? Click here to claim and customize this page!

CollPoll WIKI

Apply to get your Tech Company News Page live on HackerNoon.com today!

COLLPOLL

collpoll.com

-- employees

Since n.d.

COMPANY RANKING

COLLPOLL

EVERGREEN INDEX #3391

RELATED COMPANIESRANK

STORIES ABOUT COLLPOLL

Representing this company? Click here to claim and customize this page!

CollPoll WIKI

Apply to get your Tech Company News Page live on HackerNoon.com today!