Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
I'm creating an iOS app that uses remote databases, sessions (login/registration), server side code, and push notifications.
I found this SDK called Parse that handles all of the server stuff like hosting, the database, cloud code, push notifications, sessions, etc... (so pretty much everything I need to do)
Is Parse SDK worth using (cost-wise) in general?
NOTE - FTR, PARSE HAVE TOTALLY CHANGED THEIR PRICING PLANS (5/2014)
these are the old plans...
With the free version, you get 1 million requests a month (I'm guessing this means requests to the database?), 1 million pushes a month, and the burst limit is 20/second.
The next version up costs $199/month, you get 15 million requests a month, 5 million pushes, and the burst limit is 40/second.
Do you think it will pay for itself if goes over 1 million requests / month, and I have to pay for the $199/month version? What if I plan on making money with my app via ads, will it earn enough?
Let's say every person accesses the database 5 times a day, that's 150 times a month, that means it will take 6,666 people until I have to upgrade. On average, will ads pay for the $199/month if I have that many people viewing the ads a day? (also, take into account that Parse is taking care of security, the cost of the servers, and maintenance)
Another thing to consider is, how difficult/costly is it to create (and maintain):
Server side code
Database management and security
Push notifications
Set up a host
Session management and security
Will the robustness, security, and ease of maintainability when using Parse will help pay for itself?
Thanks!
As someone who has looked into this before, to see if its "worth it" it depends on a few things. And i have a few questions followed by some answers if these are your cases.
Does your app cost?
If not then look at how you are going to make the money, will you cover the expenses? I Imagine even with advertising only on a free app you will be making enough money to cover the expenses. If you start to have "too many" requests.. that's a GOOD thing! it means you have a lot of users or active users which in an advertising sense, is good. Or even in a paid app sense.
Does your app have a bunch of requests operations?
For example, in my app we have a chat system, obviously that's going to be a heavy load on requests. Take that into consideration
Are you in a hurry to develop?
If your in a hurry, obviously go with Parse, they handle a lot of great things for you and is a really amazing product. fast secure and reliable.
So if you're in a hurry, and are expecting users. Then go for it! Even if you don't get users, you can always go with Parse Free and when you reach your limits with Parse Free, you should have enough users to start paying and upgrading your services.
Also, paying for server maintenance is no joke. The only reason we do not use parse, is because of the fact that we like to have control. And even Parse is giving you more and more control each release.
Once Push Notifications have been implemented and are being used, there's really no maintenance after that.
In a nutshell, yes. Parse allows developers with little to no infrastructure to execute on an idea without the need to pre-purchase hardware in anticipation of traffic or scale overnight if an idea goes viral.
Another way to look at it is - Would you rather focus on the app/idea or the backend infrastructure along with maintenance? Personally I almost consider the $199 the cost of doing business so to speak and allowing me to focus on implementing new features.
Ads and donations will help make a dent but it's the ease of upgrade where they are most beneficial. Updating your own personal hosting can be anything but easy if your app gains critical mass overnight.
PS - Check out their docs for some quick ways to implement things such as log in pages: Parse Login and Signup Views
Reference: I've used Parse with some indie projects and in an enterprise setting.
Related
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 7 years ago.
Improve this question
Here is my dilemma, right now I am developing a social media app using Parse as my backend service and its working just fine. While doing some research today, I realized that if my app gains in popularity quickly using Parse will become very expensive or just stop requests all together that go over the limit.
1) Basically my question for you all is, in your experience with Parse how effective is it for handling apps with many users?
2) Also, do many users equate to many requests per second or is there an efficient way to develop my app that will keep the requests per second down?
3)And lastly would it just be easier/feasible to develop my own backend service for my app (I have no backend experience, so I would have to teach myself)? I am not opposed to doing this; I just know it will add development time but could be the best option in the long run.
Thanks for all your help.
1) We use Parse in our most of apps and Parse is handling things great. One of our app that uses Parse, has 3k monthly user and everything is going well
2) You should develop your app to make requests minimum. You must get lots of data as possible as you can. This will drop your request number.
3) I can recommend you that you should begin with Parse-like systems. We are in a time of hurry, so you must act lean. If Parse will not be enough for you in future, this is a thing that you must be happy about it. You can develop your own backend service meanwhile.
Though it is good you are planning ahead parse or something similar like amazon is gonna be way better for scalability. If you get a domain and have a mysql database (or whatever else) that you maintain the scalability isn't as good as using a service that handles all of that.
I created my own backend and I wish I hadn't wasted the time. I now will most likely have to find a service for scalability reasons so really just wasted my time making it. That is just my two cents other people may disagree
I think that building your own backend is very difficult and time consuming. Take a look at CloudKit, it gives you much better quotas than parse for free. Please note that you need an enrolled developer account to use it. Personally, I am making my app with Parse, and if I make it to be ready for release, I enroll into the programm and change the code to work with CloudKit, or leave it with Parse and if Parse quotas are nearly over, then I change to CloudKit. But Parse free quotas are quiet big as I experienced.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
Questions asking us to recommend or find a tool, library or favorite off-site resource are off-topic for Stack Overflow as they tend to attract opinionated answers and spam. Instead, describe the problem and what has been done so far to solve it.
Closed 9 years ago.
Improve this question
Can any one help me out to clear my doubts i am trying to implement an SIP application, I already have sip server setup and i have the username and password of my sip account.
Now I tried using PJSIP & SIPHON but somehow failed with lots of errors.
Then I tried with LinPhone and it worked fine.
Then copied the files from LinPhone project into my project and still working on it. (What else should I copy in my project to get going - i have copied the apple-darwin include & lib folder in my application)
I want to use G711(Both A and u) codec in the application and I can't find any header file's for that, please can any one suggest me how should I use G711 codec with the LinPhone Library in my Application?
Also can any one tell me that how many days it takes to cover up the SIP application without video functionality in it? (Audio Calls with GSM,Speex,G711 Codec's - only)
How many days will and Expert & Medium Level Developer will take to make app like this without any prior knowledge of any SIP app? (Any Rough idea according to you.)
Is there any other good open source library available to use easily to make an app like this?
Or any kind of a tutorial available? (Documentation of LinPhone is not upto the mark).
Am i going in the right direction?
Word of warning
This may sound like I'm trying to disuade you from persuing this endevor. Far from it, SIP is a fun protocol to work with (eventually) and it's very rewarding to see it all come together. You will enjoy a great deal of satisfaction at having gotten such a beast to work, and I wish you the best of luck in shaping it to your will! However, be prepared: SIP is a frustrating beast to work with.
The following timeline is based on my own experience, though I've shortened timelines somewhat due to there being two of you. Our dev cycle lasted nearly a year, but I was both the lead, and only programmer on the project, and that time includes all the work done on the UI, requirements coordination, planning, documentation, etc.
Week 1 & 2
SIP is a complex specification, with many extensions and peculiarities, especially relating to firewalls, forwarding, branching and joining. I would recommend you start looking up RFCs, and simply devote a good amount of time to reading the signalling specs, and any extensions you will need for your application, including at a minimum, the base specification, the SDP specification, and the ICE protocol specification.
That should occupy about a week if you're doing it right, and full time. For week 2, consider which extension specifications you'll need (presence indications, preconditions, conferencing, GRUU, etc) and spend the time to read those as well. Drill each other on them, it's a lot of information, and it's relatively complex in terms of how they all inter-relate to each other.
Break out the protocol analysers (Wireshark, etc) and see what the apps you have are doing on the wire. Having read the specs, you'll now be in a good position to understand why various SIP products have difficulty playing nice with each other, and, an idea of how to start working on your own app.
Week 3-6
Even with a decent toolkit, you will spend the better part of a month getting SIP to reliably do what you want it to in communicating signalling information, and writing the required infrastructure to respond to SIP signals. There are a crazy number of edge cases, and every pitfall you can imagine in concurrent processing is now magnified by the fact that you have three independent agents, some of whom will have very high latency, unreliable network connections, all trying to co-ordinate regarding the same transaction.
Don't take shortcuts, code, test, code more, look for faults and edge cases, and keep going. The RFCs help A LOT in understanding the problems you will run into, but some of it just has to be trudged through.
Week 7 & 8
Depending on the requirements for your application, just establishing the underlying connection between end-user agents will rightly occupy most of your effort to create a reliable product. You will, between the two of you, likely spend the next couple of weeks getting this part to work for the first time, and likely uncountable hours diagnosing edge conditions throughout the rest of the dev cycle of the app. Remember that there are edge cases here which require a media proxy, and a no-win edge case where the user is so badly firewalled that nothing can be done. Don't forget to handle them.
Week 9-11
At this point, your phones should (fairly) reliably connect to each other, depending on your experience and network knowledge, over fairly strict firewalls as well. The preconditions spec is very useful for decreasing perceived delay here, as you can hold off on ringing until the network layer has already connected. My experience will not inform the next layer (protocol) very well, as with Java, the media encoding and decoding was handed to me on a silver platter, aside from quicktime, which I had to do myself. I would chalk up a week or two for getting the protocols working nicely, and communicating protocol information reliably via SDP, but this may be a very optimistic estimate on my part.
Add another week if you've never worked with RTP/RTCP before, as while they're not complex per-say, properly responding to the feedback you get from RTCP can be challenging, and is somewhat of a dark art, though quite critical to ensuring optimal network utilisation and media quality.
Week 12+
Likely, at this point, you'll realise that one or another SIP product you want to be able to connect with, doesn't like your implementation, sometimes for reasons utterly inexplicable. If you need to support finicky products, you will spend the next few weeks to a month diagnosing why. If your product is proprietary, you probably don't care about this step, but it's also a way of double checking how badly you're mangling the spec. (We all do, so don't assume the test product you're using is correct either! Always double check!)
Additional
Bear in mind, the above is mainly intended as an estimate of how long it will take to get a well-written SIP/SDP/ICE based solution functioning, not the app using such infrastructure. UX is king in the iOS world, so make sure your app is compelling, and spend a LOT of time getting it right.
Even if
you use a library to make the coding easier, learn the underlying protocol! It will benefit you tremendously to understand why things work the way they do, and why the SIP universe is full of so many broken products.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 2 years ago.
Improve this question
I'm developing a website in Ruby on Rails to sell valuable goods. We need to have a very secure payment system in order for people to purchase stuff online.
Companies like PayPal seem to take a big commission, so we are wondering how sites like 99 designs or ugallery handle payments?
I'm a programmer, but until a year or so ago, I was entirely coding in C++. 2 months back, I switched to Rails and I have a little bit of experience in that, but I want to know what the best way is to tackle this problem. Obviously, I want to make sure that my customers know our system is fully secure, but I have 0 experience in developing commercial websites like this.
What pitfalls should we be aware of? Any examples I can look at? Are there Rails gems that we can leverage to set this up? How do we go about getting our site verified by a McAfee/Verisign/whatever (and is this necessary?)
It depends on what your goals are:
Stripe is great if you're looking for super easy less than an hour to setup type system. They have comparable or lower rates than you'll find else where at 2.9% + $0.30. What you'll find is other places do the same base rate, but they have monthly fees or other fees you'll have to pay. Stripe doesn't have any of these fees.
If you're looking to not get killed per transaction checkout Dwolla. They only charge .25 per transaction. The people paying on your site will need to register for a Dwolla account, but it's pretty easy to do and as it becomes more common more and more folks will have one.
The best and easiest way to have a secure payment system is to have as little to do with it as possible. I've heard good things about Braintree Payments -- especially about their client libraries. (Though Square definitely has the "buzz" these days as the new hip and cool payment processing vendor.)
Whoever does your purchase processing will take a cut. It's part of the convenience of not counting $100 bills and checking each one with test-pens and loupes to ensure you're not being taken.
I giggle every time I see a "Verified by McAfee" or "Verified by Verisign" logo on a web site. I don't know what they actually do to "earn" that badge, but in my mind I imagine it mostly starts and stops with a payment of $$$ and periodically checking that the site's SSL certificate hasn't expired. I can't imagine that they actually have a team of hackers looking for weaknesses in websites constantly and they absolutely cannot provide any assurances that the site hasn't been hacked -- unless they also provide hosting. Maybe ask your payment processor if their clients have noticed any sales increase / decrease with the little logos or if there is any actual value to these products. I doubt it, but perhaps someone else has hard numbers.
try spree
In terms of pricing, all payment gateways are more or less the same. The thing you need to worry about more is security. Your customer's confidential information would be vulnerable if you don't use secure payment gateways.
When comparing security, Stripe is the most secure platform. It provides PCI-Compliance and uses high-risk radar and 3D security to prevent malicious attacks. It charges 2.9% + 30¢ per transaction. In the second position, I would place Square, it is a powerful platform and protects customers' information through the machine learning model. Square charges 2.6% + 10¢ per transaction.
This blog regarding the [best WooCommerce payment gateways][1] will help in better comparison against prices and security.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
I'm trying to decide between Heroku and Engineyard.
Heroku seems so much better but they charge for everything and their prices are crazy!
Why one should use Heroku over EY or vice versa?
Heroku makes setup and launching of an app super-simple. You will be dependent to some degree on versions that Heroku supports (for instance, I heard today of a bundler versioning issue).
One thing to take into account with any "managed full-stack" solution like Heroku or EY is cost. You don't have to hire an ops person or have ops expertise, but you're still paying. Storage is where things get really expensive. Crank up your DB to a more than a few GB and watch the price go up.
We have in-house ops (was me doing it while coding, now a dedicated person) and run on Joyent. A big cost savings was having a few master-slave DBs and sharing them among a few dozen applications. We essentially have 100 Facebook apps running on Joyent at the same cost as 10 apps on Heroku. But this doesn't take into account the ops salary/time.
Everyone's needs are different, but the great thing is that its easy to experiment with these cloud deployment tools in quick fashion, and you will find that they each have their own strengths that you can leverage as you need.
What is most valuable to me, and my smaller clients, is to be able to experiment and get end-user feedback quickly. I have startup clients that want to be able to push out new ideas and test them quickly, deploy different combinations of ideas to different markets, get customer feedback, and keep moving forward. Launch a facebook app, a test server for an API integration client, a lightweight 'freemium' version of a product, etc. As traffic picks up, we make changes to scale up, and the increase in cost is never out of bounds (eg. our hosting costs are still well under the increase in value/revenue/marketing juice, etc).
EngineYard lets you play around with 500hrs for free, and you can easily turn it off when you are not using it, to stretch the 500hrs out. You can deploy your app quickly, deploy a CI server (that updates the app on every successful build), create a backup of your app or 'staging' server and see how it goes.
Amazon will give you 750hrs per month for free, for a year, if you are a new AWS customer. You can use this for a super fast CI server, hard-core image processing, batch reporting, whatever.
Personally I happen to use Heroku the most, as it just seems to work the best for my needs. I can put together a new application with full monitoring, backup, analytics, email, etc really fast, and feel confident in how to manage my setup (and confident that I can bring another person on board, and their learning curve will be pretty easy). As a freelancer, my use of Heroku has brought my setup time down to almost nothing, so I'm able to focus my time on understanding the business, and developing a great product. I'm not saying that can't be done on other platforms, I'm just saying heroku is working great for me in that way.
I do have one app that processes Voip data over UDP, so I'll need to figure out if I prefer amazon or engineyard for that (heroku won't let you open a UDP port, as far as I know).
I recently put together a presentation on these tools, and how I use them. (it was for newer developers, so it may be too basic for this audience, but there is a list of pros/cons that others may find useful)
Also, I think this conversation does belong here, and not necessarily on a webmasters forum, because the choice of hosting platform will influence your development capabilities and architecture, and the people making the decision are developers, not 'webmasters' or systems people.
I'd vote to use EngineYard over Heroku. Although you can probably deploy a large scale application on Heroku, there's a lot of lock-in you'll have to endure and the pricing can become crippling at higher levels of use.
EngineYard does provide application-level support, too, which is a fair bit better than what Heroku does.
If you're making a quick hobby application or simple demo site, Heroku is great for launching small, simple instances. If you're building a real application where it will need to scale, use EngineYard.
We have been running our platform on Heroku for about 9 months, and I am very satisfied.
I think the biggest complaint that most people have is that it gets "expensive" when your site gets large or high traffic. Personally, I think it is much more effective to focus on growing your business or improving your value proposition than maintaining servers or figuring how to get Rails working. (It is no easy task unless you want to spend a lot of time figuring it out). I would much rather pay Heroku to manage the servers for me than hire someone.
Here's what's great about Heroku:
Pretty easy to use. I didn't know anything about Rails when I got started, and Heroku was simple to get working.
Good documentation for most things.
OK tech support.
Extremely cost effective when you are small.
Heroku is pretty smart, and I am sure they are going to read this, so here's what can be improved:
Tech support: Typically you ask a question and they respond, and that begs a new obvious question. The tech support person should answer the next question I am going to ask. For example, I might ask how to do something, and then they tell me a certain way of doing it. Now I need information about it. Supply all the information in the first response, so I don't have to ask, "How do I use it?"
Documentation: Everyone has the same questions. The documentation could be greatly improved by adding all the questions and answers that I have asked, let alone the tens of thousands of other customers.
Logs: The free logging options are useless, and $100/month for real logs is silly. Our solution has been http://papertrailapp.com which has been outstanding. Use it.
I might as well throw my opinion in here since I have "tried" to use EngineYard and "successfully" use Heroku. While I think both are potentially good choices, I found deploying to Heroku much easier. The ala-carte pricing for Heroku add-ons may add expense, but it also gives you the opportunity to add functionality immediately to your app. The largest expense for our app is the actual web dynos, followed by the database. Heroku has a great selection of add-ons, many of which are free or low cost.
EngineYard also seems like a great company but I think they "hold your hand" a little less than Heroku. For my company, the benefits of Heroku outweighed the cost issue. The read-only filesystem which is a platform feature of Heroku also forces you to learn some new tricks.
I now have several apps (small to medium) on Heroku and happily have my assets served up from s3.
In the end, I would encourage you to try them both. EngineYard offers a 500 hour trial (though that is computing hours, not necessarily real-time hours) and Heroku let's you get started right away for pretty much free.
PS: When selecting add-ons consider your choice carefully, just like when you choose gems for your project. I have experienced an add-on that I was using, simply flaming out and had to scramble to replace that functionality. What was it? Progstr-Filer, which I was using for file uploads. That was a lesson learned.
It depends of the condition. On some case, it's highly expensive
Here we can get a 24 GB o RAM dedicated server for 99 euros.
I can have it set up an running my rail app in less than half an hour, with a mongodb database, as many runner that I want, etc...
Additionally, I can add "small" other project (the ones that costs between 15$ and 35$ monthly at Heroku)
If your business require huge amount of data and processing power, my advice is to use a dedicated hosting and spend the time in managing and monitoring your app.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 5 years ago.
Improve this question
I struggle with finding a good medium on communication. In our jobs, it seems like it's very easy to get lost in code and lose track of time. It also seems kind of ridiculous to send out updates for every tiny task. Even though I am working very hard on getting things done, in a company that has very active communication between other branches, it tends to look bad for me when I'm not constantly updating my status. However, if I'm working on a 3-4 hour project, I'm not going to update management for every single line of code that I output.
Broad I know, depends on the people, company, etc, but what would be a good general rule of thumb for effective communication?
You need to understand why managers need your communication. I have run development teams in the past, and I am currently a coding grunt, so I have seen both sides of the communication.
Managers usually don't have time to be intimately involved in your coding, mainly because they often also have to deal with other coders in your group, testers, senior management, product mangers, customers, human resources, etc.
Your manager has committed to deliver software, and has entrusted you with delivering some of it. Because (s)he does not have time to deal with you, (s)he needs to trust you. (S)he trusts you to focus on your work and deliver the software. If you mess up, (s)he will get hurt too.
The purpose of communication is to demonstrate knowledge of purpuse, to show focus, and to demonstrate results. Here are major forms of communication.
A high-level design communicates that you know what you were entrusted to deliver. It doesn't have to be fancy. I am comfortable with rough sketches of a good data model, detailed key use-cases, and interfaces to 3rd party software.
A development plan shows plausibly that you understand the steps required to deliver. I find that delivering working use-cases is best whether I'm a manager or a coder because it is an unambiguous way to independently verify completion of useful work.
Regular status updates are good because they demonstrate focus. As a manager, I don't care if you have worked on this or that. I care about what you have delivered. From a developer's point of view, a good time to deliver a status report is when you commit code to source code control. Of course, you need good comments to show that you are delivering according to the plan. It is also a natural time to deliver because it represents an end to a "flow" or a period of being "in the zone".
Flagging roadblocks is important because it demonstrates both knowledge of purpose and focus. A good manager will help you resolve these, but (s)he has to know about them.
Dealing with bugs is a particularly sensitive time, because a bug represents a breakdown of trust because, in your manger's mind, you didn't deliver what you said you would. Being extra-communicative here is very important.
Over time, good communication will build up good trust, and ultimately it is the quality and quantity of your work that will determine your trust.
For that 3-4 hour project, you must make status updates when you start it, when you finish it, and on any code-commits you do in the middle (but if you don't, that's fine too).
Agile methodology says you should have 2 week cycles on code development. I think the same is true on communication on big projects. I try to have a major communication every 2 weeks. That includes the status I have on all of my projects and everything. This can be in the form of an email, phone call, or face to face. The only reason to communicate more often than that in my opinion is if you have run into a road block and need your managers help to overcome it or if you are working on a project or task that they need feedback on when completed. In general this keeps unneeded communication to a minimum.
Another approach is to go see your manager directly and ask them what type of communication they want and how often. In general good managers only want updates when there are major issues or on a weekly/monthly interval. You need to discuss with them what is enough to keep them in the loop but not waste your or their time.
This is an interesting question as it high-lights the verbal capacity of a programmer who ends up getting all-consumed in the process of coding that everything else seems "irrelevant", been there, done that with disastrous consequences!
DO NOT BE AFRAID TO SPEAK UP....
If there's something that is bothering you when you code...try talk to them in simplistic terms, ultimately, management do not want to know the intracies of pointer manipulation, TCP/IP stack, control re-freshes upon WM_PAINT, mapping network drive dynamically to obtain some data....you get the drift....
Speak clearly and concisely, be abstract....instead of saying something in wrt to say...pointer manipulation and seg-faulting, just say "There's some issue with the internals of the code that is causing it to misbehave, I'll estimate an n time to remedy this and get it documented and mark the issue resolved asap" where n is a quantity of time, be it minutes/hours/days/weeks or even worse months/years....
If you follow that pattern, that's what management wants to hear, if they hear the proactive approach, that is where you gain rapport and trust, and the level of trust will deepen. There is of course a 'slight hitch' with that...the management might end up piling on a load of trust which equates to responsibility for your coding....be careful there...do not flatter yourself in thinking "Gosh, they like me" at the same time burdening you with "responsibility" of the code....there's a fine balance between communicating and what they want to hear...by the way, I absolutely hate the concept of kissing one's ass in order to get ahead...DON'T!!!!
The moral and bottom line, (my being deaf and finding communication extremely frustrating and made to feel as if I'm put down or not being listened to, it's hard to deal with that because I could easily mis-interpret or mis-understand what's been said, that's my experience of it) speak clearly and do not be afraid to speak out no matter how big or small a coding challenge is or if the challenge is insurmountable and after all, that requires team effort. Share it with the team. I would be wary if nothing is shared and each in the team are in isolation and nothing being said...that's fishy....
Ultimately, lots of communication is good, but if you're in the zone (and believe me, I know how hard it is to come out of the zone once you're in it) find other ways to communicate without losing flow.
Communication can take many forms. If you've got a list of features and can check them off in some way, communication can be as simple as firing off an email for every feature. If you have an issue tracking system, communication can be as simple as updating the issue when you fix/implement it.
To update business stakeholders on your progress? I do this weekly.
To find out from business stakeholders more details about what I need? Several times a week, sometimes several times a day, always either scheduled or impromptu over instant messenger.
To talk to a project manager? As often as it takes to make me more efficient.