10 interesting stories served every morning and every evening.
Hoppa till huvudinnehåll
Physical buttons are increasingly rare in modern cars. Most manufacturers are switching to touchscreens — which perform far worse in a test carried out by Vi Bilägare. The driver in the worst-performing car needs four times longer to perform simple tasks than in the best-performing car.
Inspiration for the screen-heavy interiors in modern cars comes from smartphones and tablets. Designers want a ”clean” interior with minimal switchgear, and the financial department wants to lower the cost. Instead of developing, manufacturing and keeping physical buttons in stock for years to come, car manufacturers are keen on integrating more functions into a digital screen which can be updated over time.
So in what way have these screens affected safety? Vi Bilägare gathered eleven modern cars from different manufacturers at an airfield och measured the time needed for a driver to perform different simple tasks, such as changing the radio station or adjusting the climate control. At the same time, the car was driven at 110 km/h (68 mph). We also invited an ”old-school” car without a touchscreen, a 17-year-old Volvo V70, for comparison.
...
Read the original on www.vibilagare.se »
Introducing the Electronic Materials Office Altar I — an ultra-low profile, wireless mechanical keyboard
forged
in premium, sustainable materials.
Altar I focuses on one idea: Less, but better. A precision machined aluminium
monobody. Slim, tactile, mechanical switches. Typographically balanced. Bluetooth. Quietly understated.
And it looks good on a desk.
Altar I is currently in private, invite only beta. To gain access,
add your email below. No spam — only info on pricing, availability and an invitation to
purchase when available.
...
Read the original on electronicmaterialsoffice.com »
Crunchy PostgresIntegrated high availability PostgreSQL solution for enterprises with always on requirements. Customers
Today I’m excited to introduce a new place for devs to polish their Postgres skills, a Postgres playground from Crunchy Data. What is the playground? Put simply it is:
With canned datasets you can load
Guided tutorials to follow along to learn about the power of Postgres
Wait?!?!? Postgres in the browser? Yep. You can jump right over to our playground and check out some of the tutorials right away. Or read on to learn a bit more on what you can do.
Postgres is awesome, which isn’t really a secret around these parts. But knowing Postgres is awesome is just the first piece, we want it to be easy and accessible for everyone. We want you to be able to take full advantage of things like rich datatypes such a JSONB, Arrays, and UUIDs. Leverage the rich set of built-in functions and index types. And be able to query your database with power to get the insights you need from your data.
All of the above is why we started compiling our own collection of Postgres tips from our team to share with you all. Today we’re going a step further with the playground where you can run Postgres in your browser and follow along with some tutorials to level up your Postgres skills.
At launch our playground includes tutorials for:
Often times the gap in trying/learning something in Postgres is having a good tangible example. The playground makes that easier by loading a dataset then guiding you step by step through an exercise leveraging that dataset in a practical way. Whether it’s just the basics of interacting with the Postgres CLI with psql , improving your querying skills with SQL, or digging into performance analysis we want something for everyone to be able to level up your skills. Our guided tutorials focus on practical uses and examples as opposed to purely academic definitions. One example you’ll find a real world scenario in computing week-over-week differences leveraging CTEs and window functions.
Some of the technical details
We’ll be doing a follow-up post on how the playground all came to be, but to give you a few of the questions you’re probably wondering offhand.
Yes, this is WASM and running fully in your web browser. Due to browser sandboxing there is no way to connect directly to the Postgres instance beyond the embedded psql interface that we establish for you. The current configuration allocates 512MB of memory for your Postgres instance, we may make this more configurable in the future. It’s in the browser, hence if you refresh you’re going to get a fresh instance, we haven’t created any persistence layers (yet). And finally, it’s early, you may run into some weird states if you do we ask that you send us what you were doing when it happened and then attempt to refresh.
This is just the beginning. We’ll be continuing to add other tutorials and features to this area. If you want to stay tuned for updates we encourage you to subscribe to our newsletter. And let us know you’re feedback @crunchydata and what you’d like to see improved. Get more delivered to your inboxDo not fill this out please: Do not fill this out please, it will be pre-filled:
Subscribe to the Crunchy Data Newsletter to receive Postgres content every month. Do not fill this out please: Do not fill this out please, it will be pre-filled:
This site uses cookies for usage analytics to improve our service. By continuing to browse this site, you agree to this use. Learn more
...
Read the original on www.crunchydata.com »
Last week I published a report on the risks of mobile apps using in-app browsers. Some apps, like Instagram and Facebook, inject JavaScript code into third party websites that cause potential security and privacy risks to the user.
I was so happy to see the article featured by major media outlets across the globe, like TheGuardian and The Register, generated a over a million impressions on Twitter, and was ranked #1 on HackerNews for more than 12 hours. After reading through the replies and DMs, I saw a common question across the community:
“How can I verify what apps do in their webviews?”
Introducing InAppBrowser.com, a simple tool to list the JavaScript commands executed by the iOS app rendering the page.
To try this this tool yourself:
Open an app you want to analyze
Share the url https://InAppBrowser.com somewhere inside the app (e.g. send a DM to a friend, or post to your feed)
Tap on the link inside the app to open it
Read the report on the screen
I started using this tool to analyze the most popular iOS apps that have their own in-app browser. Below are the results I’ve found.
For this analysis I have excluded all third party iOS browsers (Chrome, Brave, etc.), as they use JavaScript to offer some of their functionality, like a password manager. Apple requires all third party iOS browsers apps to use the Safari rendering engine WebKit.
Important Note: This tool can’t detect all JavaScript commands executed, as well as doesn’t show any tracking the app might do using native code (like custom gesture recognisers). More details on this below.
InAppBrowser.com is designed for everybody to verify for themselves what apps are doing inside their in-app browsers. I have decided to open source the code used for this analysis, you can check it out on GitHub. This allows the community to update and improve this script over time.
* Option to open in default browser: Does the app provide a button to open the currently shown link in the default browser?
* Modify page: Does the app inject JavaScript code into third party websites to modify its content? This includes adding tracking code (like inputs, text selections, taps, etc.), injecting external JavaScript files, as well as creating new HTML elements.
* Fetch metadata: Does the app run JavaScript code to fetch website metadata? This is a harmless thing to do, and doesn’t cause any real security or privacy risks.
* JS: A link to the JavaScript code that I was able to detect. Disclaimer: There might be other code executed. The code might not be a 100% accurate representation of all JS commands.
Click on the Yes or None on the above table to see a screenshot of the app.
Important: Just because an app injects JavaScript into external websites, doesn’t mean the app is doing anything malicious. There is no way for us to know the full details on what kind of data each in-app browser collects, or how or if the data is being transferred or used. This publication is stating the JavaScript commands that get executed by each app, as well as describing what effect each of those commands might have. For more background on the risks of in-app browsers, check out last week’s publication.
Even if some of the apps above have green checkmarks, they might use the new WKContentWorld isolated JavaScript, which I’ll describe below.
When you open any link on the TikTok iOS app, it’s opened inside their in-app browser. While you are interacting with the website, TikTok subscribes to all keyboard inputs (including passwords, credit card information, etc.) and every tap on the screen, like which buttons and links you click.
* TikTok iOS subscribes to every keystroke (text inputs) happening on third party websites rendered inside the TikTok app. This can include passwords, credit card information and other sensitive user data. (keypress and keydown). We can’t know what TikTok uses the subscription for, but from a technical perspective, this is the equivalent of installing a keylogger on third party websites.
* TikTok iOS subscribes to every tap on any button, link, image or other component on websites rendered inside the TikTok app.
* TikTok iOS uses a JavaScript function to get details about the element the user clicked on, like an image (document.elementFromPoint)
Here is a list of all JavaScript commands I was able to detect.
The company confirmed those features exist in the code, but said TikTok is not using them.
“Like other platforms, we use an in-app browser to provide an optimal user experience, but the Javascript code in question is used only for debugging, troubleshooting and performance monitoring of that experience — like checking how quickly a page loads or whether it crashes,” spokesperson Maureen Shanahan said in a statement.
The above statement confirms my findings. TikTok injects code into third party websites through their in-app browsers that behaves like a keylogger. However claims it’s not being used.
Last week’s post talked about how Meta injects the pcm.js script onto third party websites. Meta claimed they only inject the script to respect the user’s ATT choice, and additional “security and user features”.
The code in question allows us to respect people’s privacy choices by helping aggregate events (such as making a purchase online) from pixels already on websites, before those events are used for advertising or measurement purposes.
After improving the JavaScript detection, I now found some additional commands Instagram executes:
* Instagram iOS subscribes to every tap on any button, link, image or other component on external websites rendered inside the Instagram app.
* Instagram iOS subscribes to every time the user selects a UI element (like a text field) on third party websites rendered inside the Instagram app.
Here is a list of all JavaScript commands I was able to detect.
Note on subscribing: When I talk about “App subscribes to”, I mean that the app subscribes to the JavaScript events of that type (e.g. all taps). There is no way to verify what happens with the data.
Since iOS 14.3 (December 2020), Apple introduced the support of running JavaScript code in the context of a specified frame and content world. JavaScript commands executed using this approach can still fully access the third party website, but can’t be detected by the website itself (in this case a tool like InAppBrowser.com).
Use a WKContentWorld object as a namespace to separate your app’s web environment from the environment of individual webpages or scripts you execute. Content worlds help prevent issues that occur when two scripts modify environment variables in conflicting ways. […] Changes you make to the DOM are visible to all script code, regardless of content world.
This new system was initially built so that website operators can’t interfere with JavaScript code of browser plugins, and to make fingerprinting more difficult. As a user, you can check the source code of any browser plugin, as you are in control over the browser itself. However with in-app browsers we don’t have a reliable way to verify all the code that is executed.
So when Meta or TikTok want to hide the JavaScript commands they execute on third party websites, all they’d need to do is to update their JavaScript runner:
For example, Firefox for iOS already uses the new WKContentWorld system. Due to the open source nature of Firefox and Google Chrome for iOS it’s easy for us as a community to verify nothing suspicious is happening.
Especially after the publicity of last week’s post, as well as this one, tech companies that still use custom in-app browsers will very quickly update to use the new WKContentWorld isolated JavaScript system, so their code becomes undetectable to us.
Hence, it becomes more important than ever to find a solution to end the use of custom in-app browsers for showing third party content.
There are many valid reasons to use an in-app browser, particularly when an app accesses its own websites to complete specific transactions. For example, an airline app might not have the seat selection implemented natively for their whole airplane fleet. Instead they might choose to reuse the web-interface they already have. If they weren’t able to inject cookies or JavaScript commands inside their webview, the user would have to re-login while using the app, just so they can select their seat. Shoutout to Venmo, which uses their own in-app browser for all their internal websites (e.g. Terms of Service), but as soon as you tap on an external link, they automatically transition over to SFSafariViewController.
However, there are data privacy & integrity issues when you use in-app browsers to visit non-first party websites, such as how Instagram and TikTok show all external websites inside their app. More importantly, those apps rarely offer an option to use a standard browser as default, instead of the in-app browser. And in some cases (like TikTok), there is no button to open the currently shown page in the default browser.
The apps below follow Apple’s recommendation of using Safari or SFSafariViewController for viewing external websites. More context on SFSafariViewController in the original article.
All apps that use SFSafariViewController or Default Browser are on the safe side, and there is no way for apps to inject any code onto websites, even with the new WKContentWorld system.
As a user of an app
Most in-app browsers have a way to open the currently shown website in Safari. As soon as you land inside an in-app browser, use the Open in Browser feature to switch to a safer browser. If that button isn’t available, you will have to copy & paste the URL to open the link in the browser of your choice. If the app makes it difficult to even do that, you can tap & hold a link on the website and then use the Copy feature, which can be a little tricky to get right.
TikTok doesn’t have a button to open websites in the default browser.
Update: According to some tweets, sometimes there is a way to open websites in the default browser.
If you’re at a company where you have an in-app browser, use it only for your own pages and open all external links in the user’s default browser. Additionally, provide a setting to let users choose a default browser over an in-app browser experience. Unfortunately, these types of changes rarely get prioritized over features that move metrics inside of tech organizations. However, it’s so important for people to educate others on their team, and their managers, about the positive impact of making better security and privacy decisions for the user. These changes can be transparently marketed to users as an opportunity to build further trust.
It’s important to call out how much movement there’s been in the privacy of data space, but it’s unclear how many of these changes have been motion vs. true progress for the industry and the user.
“Many tech companies take heat for ‘abusing their users’ privacy’, when in fact they try to balance out business priorities, great user experiences, and ensuring they are respecting privacy and user data. It’s clear why companies were motivated to provide an in-app experience for external websites in the first place.
With the latest technology, companies can start to provide a smooth experience for the user, while respecting their privacy. It’s possible for iOS or Android developers to move the privacy standards and responsibility to Apple & Google (e.g. stricter app reviews, more permission screens, etc.), however this is a much larger conversation where companies need to work together to define what standards should exist. We can’t have one or two companies set the direction for the entire industry, since a solution needs to work for the large majority of companies. Otherwise, we’re left in a world where companies are forced to get creative on finding ways to track additional user data from any source possible, or define their own standards of what’s best for user privacy, ultimately hurting the consumer and the product experience.”
Technology-wise App-Bound Domains seems to be an excellent new WebKit feature making it possible for developers to offer a safer in-app browsing experience when using WKWebView. As an app developer, you can define which domains your app can access (your own), and you won’t be able to control third party pages any more. To disable the protection, a user would have to explicitly disable it in the iOS settings app. However, at the time of writing, this system is not yet enabled by default.
* Can in-app browsers read everything I do online? Yes, if you are browsing through their in-app browser they technically can.
* Do the apps above actually steal my passwords, address and credit card numbers? No! I wanted to showcase that bad actors could get access to this data with this approach. As shown in the past, if it’s possible for a company to get access to data legally and for free, without asking the user for permission, they will track it.
* How can I protect myself? Whenever you open a link from any app, see if the app offers a way to open the currently shown website in your default browser. During this analysis, every app besides TikTok offered a way to do this.
* Are companies doing this on purpose? Building your own in-app browser takes a non-trivial time to program and maintain, significantly more than just using the privacy and user-friendly alternative that’s already been built into the iPhone for the past 7 years. Most likely there is some motivation there for the company to track your activities on those websites.
* I opened InAppBrowser.com inside an app, and it doesn’t show any commands. Am I safe? No! First of all, the website only checks for one of many hundreds of attack vectors: JavaScript injection from the app itself. And even for those, as of December 2020, app developers can completely hide the JavaScript commands they execute, therefore there is no way for us to verify what is actually happening under the hood.
...
Read the original on krausefx.com »
Many FreeBSD ports and apps, Linux apps, and even trivial Darwin & macOS binaries can run on ravynOS. And we’re actively working on improving it!
Many FreeBSD ports and apps, Linux apps, and even trivial Darwin & macOS binaries can run on ravynOS. And we’re actively working on improving it!
We’re building familiar apps native to ravynOS, packaged as portable .app bundles and built with our core technologies of Cocoa, Qt, and Mach. These are guaranteed to work and fit seamlessly into your desktop.
FreeBSD ports that support Wayland continue to work on ravynOS right out of the box, or with minor changes.
Many Linux applications that support Wayland are expected to work with FreeBSD’s Linux emulation layer.
Trivial macOS and Darwin applications may run directly on ravynOS. This is an active area of work and research. AppKit-based source code may build and run natively.
...
Read the original on ravynos.com »
From Day 1 to Gear Making Guru
Ultimate Guide and Essential Tools
Show me the way!
Opt In for New Patterns
...
Read the original on learnmyog.com »
I know what you’re thinking…. another “old guard” geezer posting about how bad things are with nothing but anecdotal evidence that this is actually the case. Before you judge me, please watch the video. I don’t believe unhappiness is unreasonable when one is forced to accept concepts such as “throw-away society” and “poor value / high overall ownership costs” and “bad ownership experience” in the name of “progress.”
The back-story to this video is as follows. A couple years ago a local gentleman brought his 1947 GE fridge to me for rewiring and re-gasketing. That job went well and he has been using that fridge ever since as a beverage fridge.
Fast-forward to last week, and his main kitchen fridge stopped working. Without warning, it started clicking on and off on the compressor overload, as if the compressor was stuck. I normally don’t work on modern appliances; however this is local and the owner was able to bring it over in the back of his pickup with little effort on his part. So I agreed to look at it.
The compressor would not start. I tried boosting with higher voltages, adding capacitors etc. and nothing would break it free. So, I ended up putting in a salvaged compressor to get his going.
Here is a video where I tear it down and inspect it for root cause of failure. Again, I need to repeat that I am not saying everything “old” is better just because it’s “old.” I am saying that this compressor, and its application, show clear engineering choices made, which sacrificed its life span in the name of some modicum of energy savings. These marginal design choices are not the only way to get an efficient unit, since the fridge compressors from the 1940′s and 1950′s era were very efficient, while having consistently longer lives. This failed unit is purely an example of doing just enough to get by until it is someone else’s problem. When it becomes a problem, it goes to the dump where all the foamed-together plastic parts will not be feasible to separate nor recycle.
...
Read the original on www.automaticwasher.org »
It wasn’t for nothing
Several friends and family members have asked me why I spend so much of my free time developing Guix. I don’t always have a good answer, but after six years I’m starting to get a sense of it.
First of all, it’s fun. It’s fun to make my own operating system. I can design it exactly how I want it, from the inner workings to the user interface.
It’s also rewarding. While I haven’t been as active on the patch tracker as I’d like lately, it gives a sense of awe and accomplishment to aid new contributors from beginners to “professionals”. It’s also something of a dopamine rush to perform huge migrations like switching to a new C compiler or Python version upgrades (these activities feel more like an addiction than a hobby, but rewarding nonetheless).
The work feels important. Guix occupies an underserved niche in the operating system “market”. Namely one that offers full reproducibility, transparency, and provenance, of every package, and every operating system generation. It also integrates a neat scripting language where you can string together any package into one deterministic script. Think of it like a shell script where every command is lazily instantiated by the package manager on demand. You don’t even have to use Scheme, you can write in your favorite language and run it through guix shell and get the same deterministic guarantees. If you note the Guix revision (as given by guix describe), you can use guix time-machine to reproduce the exact same environment in the future, bit by bit (at least in theory).
Guix is pure. It’s refreshing to know that I can take any package and reuse its source code for my own purposes without having to worry about commercial restrictions or redistribution. It’s reassuring to know that all packages are bootstrapped and not just some random binary blobs. Guix is also immensely hackable, it’s easy to add extra packages or services without submitting them, either by creating a channel or “inlining” straight in the OS configuration.
But most importantly, Guix saved my life. When I first started contributing to Guix I did not have any direction in life, any sense of purpose or belonging. I’d been using GNU/Linux for a long time, been a “power user” of Debian, Gentoo, and NixOS, but did not contribute much to any either because packaging was too much work, or I didn’t enjoy the community, or I found the packaging standards “too low”. With Guix I finally felt home, it ticked all the boxes, the language is a joy to work with (even though it felt weird in the beginning), and it also desperately needed developers.
I know some are disappointed that I have prioritized a hobby over doing “normal” things like chasing an exciting career or strengthening my social network. But without Guix I would still be a confused alcoholic with daddy issues crashing on someones couch. I have now been with Guix for longer than I held any job, and am finally feeling some stability in life; and a desire to explore other creative outlets such as blogging (hi!), cooking, growing sustainable foods; and healthy activities like climbing and skiing.
None of this would be possible without Guix, and the (occasionally reluctant) support from my awesome friends and family. So thank you. It wasn’t for nothing. Rather the opposite.
...
Read the original on gexp.no »
As a payment operations startup, accounting principles are core to our work. We have seen them implemented at scale at some of the largest fintechs and marketplaces. Yet, accounting seems like an arcane topic when you’re starting out. This HackerNews thread, for example, is rather representative of the state of confusion around the topic.
Over the years, there have been many accounting for developer guides published (two great ones are Martin Blais’ and Martin Kleppmans’), but we wanted to add our two cents to the discussion. In our experience, a concepts-first approach to explaining accounting comes in handy when you are designing systems that move or touch money.
This post is divided into two parts. Part I covers the foundational accounting principles. Part II will show how to bring it all together by walking through how to build a Venmo clone.
This guide is designed for developers that work on applications that handle money in any way. You may work at a fintech company (the data you handle is money), or perhaps you are responsible for managing the fintech integrations in your startup (you handle data and money). We think that every engineer that builds or maintains such systems benefits from knowing the core principles of accounting.
Double-entry systems are more reliable at tracking money than any other viable alternative. As a payments infrastructure company, we often get to see the architecture of some of the most successful software companies. One design is constant: they use double-entry accounting in their code. Some build their applications from the start with accounting concepts in mind, but in most cases, companies begin incorporating these concepts only after their original code starts causing problems.
When software fails to track money properly, it does so in a number of common patterns. The most common failure mode is software accidentally creating or destroying records of funds. This leads to all sorts of inconsistencies. Every developer we know has horror stories about explaining to their finance team why a customer is owed money or what caused a payout to have an unexpected amount. Internal records differing from bank statements, reconciliation engines gone awry, balances that don’t make sense given a set of transactions—these are all problems that can be mitigated with double-entry accounting. For more evidence that double-entry systems are a good standard for scalable applications, see the stories of Uber, Square, and Airbnb.
The core principle of double-entry accounting is that every transaction should record both where the money came from and what the money was used for. This guide explains why that is and how it works.
An account is a segregated pool of value. The easiest analogy here is your own bank checking account: money that a bank is holding on your behalf, clearly demarcated as yours. Any discrete balance can be an account: from a user’s balance on Venmo to the annual defense spending of the United States. Accounts generally correlate with the balances you want to track.
In accounting, accounts have types. More on this later.
Transactions are atomic events that affect account balances. Transactions are composed of entries. A transaction has at least two entries, each of which corresponds to one account.
Let’s use a simple Venmo transfer as an example. Jim is sending $50 to Mary:
The entries in this transaction tell which accounts were affected. If each user’s balance is set up as an account, a transaction can simultaneously write an entry against each account.
Now, let’s expand this model with more accounts and a handful of additional events:
Here I have a ledger—a log of events with monetary impact. We often see developers mutating balances directly rather than computing a balance from a log of transactions. This is suboptimal.
While mutating a balance directly is more efficient and simpler to implement, it’s more accurate to store immutable transactions and always compute balances from those transactions. Mutating balances directly creates a system that is prone to errors, as it becomes non-trivial to detect and reconcile inaccuracies.
Notice how each transaction has multiple entries. Each entry belongs to a transaction and an account. By comparing entries side by side, one can clearly see where the money came from and what it was used for. Double-entry ensures that, as transactions are logged, sources and uses of funds are clearly shown, and balances can be reconstructed as of any date:
This core idea—one transaction, at least two entries, one representing the source and the other representing the use of funds—is one of the foundational ideas of double-entry accounting [1]. We’ll expand more on this later.
As mentioned before, another big innovation of accounting was giving types to accounts. The two types we will cover here are debit normal and credit normal.
* Accounts that represent funds you own, or uses of money, are debit normal accounts.
* Accounts that represent funds you owe, or sources of money, are credit normal accounts.
Let’s illustrate that with a simple table with two columns, the right side listing credit normal accounts and the left side listing debit normal accounts. We will place accounts that track uses of funds on the debit normal side and accounts that track sources of funds on the credit normal side.
Examples of uses of funds are assets and expenses. Buying inventory, making an investment, acquiring physical property, and so on. The term “use” here is broadly defined: letting cash sit in a bank account is a use of funds, as well as selling on credit to someone else (you are effectively ‘using’ the money you’d get on a sale by extending them credit). The accounts that represent these balances are all debit normal accounts.
Conversely, sources of funds—such as liabilities, equity, or revenue—can mean bank loans, investors’ capital, accumulated profits, or income. “Source” is broadly defined here, too: if you are buying on credit, for instance, that is a “source” of money for you in the sense that it prevents you from spending money right now. Accounts that represent these balances are credit normal accounts.
Here is a handy table with the different account types:
Some of the guides we mentioned at the beginning of this post advise developers to “save the confusion and flush out debits and credits from your mind.” We do recognize that debits and credits can be challenging to grasp, but we think fully mastering these concepts is important when creating transaction handling rules.
Part of the confusion is that “debits” and “credits” are often used as verbs: to debit or to credit an account. Debits and credits can also refer to entries, for example:
This sample transaction has two entries: we’re debiting our cash account and crediting our equity account for $1M. Save for a few special situations, accounting systems only log positive numbers. The effect on balances will depend on whether the entry is on the “debit side“ or “credit side.”
Debits and credits are a shorthand for the expected effects on accounts, depending on their type. A credit entry will always increase the balance of a credit normal account and decrease the balance of a debit normal account. Put differently:
Let’s continue to model out a few transactions to drive this point home. Let’s use a fictitious startup called Modern Bagelry—an eCommerce store for premium bagels.
In this example, we will use four accounts: Cash and Inventory (both debit normal accounts) as well as Equity and Loans (both credit normal accounts). Let’s say this ledger starts on a day T, and we are measuring time in days.
A common misconception is that one account needs to decrease while another needs to increase. However, they can both increase or decrease in tandem, depending on the debit and credit entries in the transaction and the account types. In the first transaction cash increases because it’s a debit entry in a debit normal account (cash); equity also increases because it’s a credit entry in a credit normal account (equity). Conversely, in the last transaction both balances decrease because we are adding a debit entry into a credit normal account (loans) and a credit entry into a debit normal account (cash).
Tracking sources and uses of funds in a single ledger with double-entry is helpful to clearly show clearly that balances match.
Let’s say we are aggregating the balances for each account in the example above right after each transaction takes place:
A system of accounts will balance as long as the balance on debit normal accounts equals the balance on credit normal accounts. The ending balances of Cash ($1.22M) and Inventory ($250k) sum to $1.47M. That is equal to the sum of ending balances of Equity ($1M) and Loans ($470k). It is said that our accounts in this example are balanced. Not matching would mean the system created or lost money out of nothing.
We’ll walk through how to implement these concepts in more detail in our next post.
Let’s recap the principles we reviewed so far:
* A ledger is a timestamped log of events that have a monetary impact.
* An account is a discrete pool of value that represents a balance you want to track.
* A transaction is an event recorded in the ledger.
* Transactions must have two or more entries.
* Entries belong to a ledger transaction and also belong to an account.
* Accounts can be classified as credit normal or debit normal.
* Entries can be added onto the ledger “on the debit side” or “on the credit side.” Debits and credits refer to how a given entry will affect an account’s balance:Debits—or entries on the debit side—increase the balance of debit normal accounts, while credits decrease it.Credits—or entries on the credit side—increase the balance of credit normal accounts, while debits decrease it.
* Debits—or entries on the debit side—increase the balance of debit normal accounts, while credits decrease it.
* Credits—or entries on the credit side—increase the balance of credit normal accounts, while debits decrease it.
* If the sum of balances of all credit normal accounts matches the sum of balances of all debit normal accounts in a single ledger, it is said that the ledger is balanced. This is an assurance of consistency and that all money is properly accounted for.
In part two, we’ll add some complexity to transaction structures, and we’ll bring everything together by doing a walkthrough of how to build a Venmo clone.
If you are a developer who works with money, Modern Treasury Ledgers simplifies the process of building a double-entry system. Reach out to us here if we can be helpful.
...
Read the original on www.moderntreasury.com »
TMC youth wing stage protest against central agencies over crackdown on party leaders
TMC youth wing stage protest against central agencies over crackdown on party leaders
Diljit Dosanjh and his antics to keep the fans entertained
...
Read the original on www.indiatoday.in »
To add this web app to your iOS home screen tap the share button and select "Add to the Home Screen".
10HN is also available as an iOS App
If you visit 10HN only rarely, check out the the best articles from the past week.
If you like 10HN please leave feedback and share
Visit pancik.com for more.