Slack Blocks? Limited by design for simple apps only? - slack-api

My application sends blocks to slack that require user decision about certain things. Let's simplify it and say it's a "yes" or "no" button click. The thing is--- the object this decision works should work on is a combination of app_domain -> element_type -> element_id -- those three fields are a MUST to identify which object to work on.
Maybe I'm reading the docs wrong, but it seems Slack is pretty limiting and there is absolutely no place to include a custom struct that'll go along with every message the ping-pong of app -> slack and slack -> app interaction. I am limited to block_id and action_id pretty much and there is absolutely nothing else I can put custom context-keeping data on. I don't get this crude limitation. Do I really have no other choice other than putting "xxxxxx|xxxxxxxx|xxxxxx" on the block_id string so that I can later decode those three IDs in my app to know what objects to work on when the user clicks an interactive button?
There's got to be a smarter way. Any pointers?

There's another customizable field in the blocks:
private_metadata
https://api.slack.com/reference/surfaces/views

Related

AWS lex slots are behaving very strange

I'm trying to create a bot in Lex and I'm using the default one provided by the platform(BookTrip). Here when I enter some random text when I as prompted for city, it is taking anything, though it is a valid city or not.
please let me know if I'm going wrong somewhere and how can I fix this.
Thanks
The built-in slot types are not limited to their lists.
So it is good practice to validate the slot values yourself in Lambda.
The built-in slots have a big room to take on values that might not be valid, this happens for cities, names, emails, etc. To avoid this is to fill out the Corresponding utterances for each slot in the console.
An advanced way would be to attach a Lambda that gets called with the intent, then verify each slot value received to verify it matches your validation

CQRS, event sourcing and a translated application

I am working on an application (CQRS + event sourcing) that should support multiple user languages. The user will have the ability to translate some of his input different languages. E.g. some labels or descriptions can be given in Dutch and/or English. Depending on the language preferences of the user, the application should show the correct translation.
I suspect the read model plays a big role in this process.
I was thinking of creating events like ItemDescriptionTranslated, telling 'The description of item X was translated to language Y as Z'.
I would think that the aggregate can safely ignore this kind of events, and that only the read models should do something with this information.
Does this make sense? Does any of you have experience with CQRS/ES in a translated application? Any hints are greatly appreciated.
Of cource you can use event sourcing. You can code aggregate's build funcs to ignore ItemDescriptionTranslated event.
The main question is - if you really need event sourcing in this part of application. For example you can build authorization using both ways - es or not. If you want to log all users' login and auth, you prefer ES. But if you want login only, without any analysis - i suggest not to use es.
So, do you want to collect some additional info about translating? When, who, maybe check some statistics about corrections by different authors and so on.

Local storage on Rails

I've built a Rails app, basically a CRUD app for memos/notes.
A notes title must be unique. If a user enters a name already taken a warning message is shown prompting them to chose another.
My question is how to make this latency for this feedback as close to zero as possible. When creating a note little UX speed bumps like this will get annoying for user quickly.
Of course the main bottleneck is the network. Inspired by Meteor (and mini-mongo) I was thinking some kind of local storage could be a solution?
I.E. When app first loads, send ALL JSON to the client with ALL note titles. The app (front end is Angular JS) could check LocalStorage (or App Cache, Web SQL?) instead of incurring a network round trip. The feedback would be instant.
I've used LocalStorage in the past to augment an app, but in the scenario it'd really seriously depend on it. I'm not sure how confident I'd be building on something that user might not have. Also as the number of user Notes/Memos I have doubts how feasible it is to send a JSON object down the wire with ALL the note titles. That might get pretty big. On the other hand MeteorJS seems to do this with no probs.
Has anyone done something similar or have any pointers? Thanks!
I don't know how Meteor works here, but you're right that storing all note titles in localStorage is not a good idea. Actually, you don't need localStorage here, you can just put it in a JS array, because you need this data only once (when checking new note title).
I think, there could be 2 possible solutions:
You can change your business requirements and allow non-unique title. Is there really a necessity for titles to be unique?
You can verify note title when user submits form. In this case you can provide suggestions for users, so they not spend time guessing vacant title.
Or, if titles must be unique only within a user (two users can have same title for their notes), you can really load all note titles in JS array and check uniqueness while users types in a title.
Or you can send an AJAX request checking title uniqueness as soon as user finished typing the title. In this case you can win some seconds.
Or you can send an AJAX request as soon as user typed in 3 symbols. The request will return all titles that begin with these 3 symbols, so you don't need to load all the titles.

Am I not understanding UIActivityViewController, or does the implementation currently suck?

I'm trying to move my app to use UIActivityViewController, rather than UIActionSheet, so that I get the fancy graphical sharing buttons rather than the textual buttons. (My app is targeted at iOS 6 only.)
After trying to work with it for a couple nights, it seems either I am totally misunderstanding how to use it, or the current implementation by Apple is terrible:
You can't specify a different message for different services. If I want something that will work across: Mail, Facebook, Messages AND Twitter, it's going to need to be 140 characters max, to work on Twitter. Is there a way to set custom content for each type of activity?
There appears to be no way to set a subject line or recipient for Mail messages. I've read the docs, they make it sound like this might be possible with an NSURL that uses the mailto: protocol, but in my tests, those URLs just get shoved into the message body. Is there actually a way to set the subject line and optionally, the recipients?
If I want to work around these shortcomings, and do my own custom activities by subclassing UIActivity, I have to use a custom image/icon. Therefore, I can't mimic the Mail activity with Apple's official icon, and e.g. implement my own custom activity backend that actually lets me set the subject line, recipients, custom body, etc. Am I wrong, is there a way to use Apple's service icons, but have a chance to customize the behavior? (The only callback I see is one that runs AFTER the activity has been completed, right?)
I hope I'm wrong!
Is there a way to set custom content for each type of activity?
Yes, I guess you should subclass UIActivityItemProvider and override method –activityViewController:itemForActivityType: with your logic (e.g. trim string to 140 chars for Twitter).
Then pass an instance of this class to -[UIActivityViewController initWithActivityItems:applicationActivities:].
Is there actually a way to set the subject line and optionally, the recipients?
You are right, the mailto scheme should be able to set these fields. If it is not working, I consider this as bug. (Didn't try this myself, but I will give it a check.)
Is there a way to use Apple's service icons, but have a chance to customize the behavior?
I think you can't do this. (Unless you want to hack those system activities.)
You are better off using a custom component that behaves like UIAcitvityController as it is quite limited, as you noted.
This is one example: https://github.com/hjnilsson/REActivityViewController , I just forked it from https://github.com/romaonthego/REActivityViewController to allow you to set the email subject field.

How to make this concept RESTful?

I have a controller dealing with sending SMS Messages, and it's set up as a default resource. Now, business requirements have changed and we want to offer the user three different ways of sending the message:
To everybody on their contact list
To a segmented portion of their contact list (predefined)
To individual contacts that they can choose
In addition, there are two ways they can send an SMS Message: Premium (via an sms gateway) or Standard (via SMTP). So there are essentially six different ways to send a message (three for premium, three for standard).
The requirements state that the three options above need to be presented in a "wizard-like" format, as three radio button choices and then a submit button which displays the appropriate form and list:
If option 1 (send to everyone) then just display a textbox for sending the SMS
If option 2 (send to a segment) then display a list of segments as radio buttons
If option 3 (send to specific) then display a searchable/sortable list of all contacts with checkboxes next to their names, and on submit select everyone checked to send.
The issue I'm running into is how to make this fit the RESTful conventions imposed by the resource. Each of these use cases is technically only one action (well, two since it would correspond to new/create) but it looks like there needs to be an inordinate amount of logic in the action then, and rather messy as well (switch statement or similar).
Is there a better way do to this?
I would consider "the simplest thing that works" approach first. Different params processing and setting up several delivery methods looks like something that cannot be easily wrapped into a pair of "new" and "create" actions.
Without knowing all the details, my first recommendation would be just to implement actions like "choose_contacts", "send_to_contacts" and "choose_segments", "send_to_segments" which either prepare the data for these use cases and render their own templates, or process incoming data and handle possible errors. Then "new" action will just dispatch processing to an appropriate action based on selected option, while "create" action won't longer be needed (or you can re-use it for sending a single message). I bet the code for sending a single message (or a set of messages) is in model anyway, so you'll just have to call it with correct arguments once you processed your form data in a reasonable way.
Benefits of this approach:
It reads more naturally by someone who will maintain your code later, as it clearly differentiates available options;
You'll have more flexibility processing an input params and handling errors from different forms, as you'll know which erroneous state to render as a response, without carrying additional data from the form. Segments and contacts probably require different processing, aren't they?
If you use some kind of a performance management application (such as NewRelic), you'll see if one of certain delivery processing actions has any performance problems much faster than in case of a general SMSDelivery#create action;
I had the similar situation with "inviting/finding friends via uploading/searching contacts" process, and the given approach worked really well for me. Overall, REST is a great convention, but trying to squeeze a lot of business logic into a CRUD sometimes is not perfect and error-prone. YMMV, I would just suggest to keep logic clear and easy to read, modifying existing conventions if you're not feeling flexible enough with them.

Resources